From 95bd8eaa7ab2b82cb67af933cbb0d69e27bd0677 Mon Sep 17 00:00:00 2001 From: Website Deployment Script Date: Thu, 27 Feb 2020 17:06:31 +0000 Subject: [PATCH] Deploy website Deploy website version based on e9a7b64316032e568ed6a134d563a06b455eed89 --- docs/0.60/typescript.html | 4 ++-- docs/0.60/typescript/index.html | 4 ++-- docs/next/performance.html | 16 ++++++++-------- docs/next/performance/index.html | 16 ++++++++-------- img/homepage/cross-platform.svg | 2 +- 5 files changed, 21 insertions(+), 21 deletions(-) diff --git a/docs/0.60/typescript.html b/docs/0.60/typescript.html index c75ed965662..286a0c843df 100644 --- a/docs/0.60/typescript.html +++ b/docs/0.60/typescript.html @@ -85,7 +85,7 @@ ignite new MyTSProject
  1. Add TypeScript and the types for React Native and Jest to your project.
-
yarn add typescript @types/jest @types/react @types/react-native @types/react-test-renderer
+
yarn add --dev typescript @types/jest @types/react @types/react-native @types/react-test-renderer 
 # or for npm
 npm install --save-dev typescript @types/jest @types/react @types/react-native @types/react-test-renderer
 

@@ -204,7 +204,7 @@ const styles = StyleSheet.create({
 
 
Using Custom Path Aliases with TypeScript

 
To use custom path aliases with TypeScript, you need to set the path aliases to work from both Babel and TypeScript. Here's how:

diff --git a/docs/0.60/typescript/index.html b/docs/0.60/typescript/index.html
index c75ed965662..286a0c843df 100644
--- a/docs/0.60/typescript/index.html
+++ b/docs/0.60/typescript/index.html
@@ -85,7 +85,7 @@ ignite new MyTSProject
 
    
 
  1. Add TypeScript and the types for React Native and Jest to your project.
    2. 
 

-
yarn add typescript @types/jest @types/react @types/react-native @types/react-test-renderer
+
yarn add --dev typescript @types/jest @types/react @types/react-native @types/react-test-renderer 
 # or for npm
 npm install --save-dev typescript @types/jest @types/react @types/react-native @types/react-test-renderer
 

@@ -204,7 +204,7 @@ const styles = StyleSheet.create({
 
 
Using Custom Path Aliases with TypeScript

 
To use custom path aliases with TypeScript, you need to set the path aliases to work from both Babel and TypeScript. Here's how:

diff --git a/docs/next/performance.html b/docs/next/performance.html
index d40e251e557..9d09651d4b5 100644
--- a/docs/next/performance.html
+++ b/docs/next/performance.html
@@ -86,18 +86,18 @@
 
JavaScript thread performance suffers greatly when running in dev mode. This is unavoidable: a lot more work needs to be done at runtime to provide you with good warnings and error messages, such as validating propTypes and various other assertions. Always make sure to test performance in release builds.

 
Using console.log statements

 
When running a bundled app, these statements can cause a big bottleneck in the JavaScript thread. This includes calls from debugging libraries such as redux-logger, so make sure to remove them before bundling. You can also use this babel plugin that removes all the console.* calls. You need to install it first with npm i babel-plugin-transform-remove-console --save-dev, and then edit the .babelrc file under your project directory like this:

-
{
-  "env": {
-    "production": {
-      "plugins": ["transform-remove-console"]
-    }
-  }
-}
+
{
+  "env": {
+    "production": {
+      "plugins": ["transform-remove-console"]
+    }
+  }
+}
 

 
This will automatically remove all console.* calls in the release (production) versions of your project.

 
ListView initial rendering is too slow or scroll performance is bad for large lists

 
Use the new FlatList or SectionList component instead. Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows.

-
If your FlatList is rendering slow, be sure that you've implemented getItemLayout to optimize rendering speed by skipping measurement of the rendered items.

+
If your FlatList is rendering slow, be sure that you've implemented getItemLayout to optimize rendering speed by skipping measurement of the rendered items.

 
JS FPS plunges when re-rendering a view that hardly changes

 
If you are using a ListView, you must provide a rowHasChanged function that can reduce a lot of work by quickly determining whether or not a row needs to be re-rendered. If you are using immutable data structures, this would only need to be a reference equality check.

 
Similarly, you can implement shouldComponentUpdate and indicate the exact conditions under which you would like the component to re-render. If you write pure components (where the return value of the render function is entirely dependent on props and state), you can leverage PureComponent to do this for you. Once again, immutable data structures are useful to keep this fast -- if you have to do a deep comparison of a large list of objects, it may be that re-rendering your entire component would be quicker, and it would certainly require less code.

diff --git a/docs/next/performance/index.html b/docs/next/performance/index.html
index d40e251e557..9d09651d4b5 100644
--- a/docs/next/performance/index.html
+++ b/docs/next/performance/index.html
@@ -86,18 +86,18 @@
 
JavaScript thread performance suffers greatly when running in dev mode. This is unavoidable: a lot more work needs to be done at runtime to provide you with good warnings and error messages, such as validating propTypes and various other assertions. Always make sure to test performance in release builds.

 
Using console.log statements

 
When running a bundled app, these statements can cause a big bottleneck in the JavaScript thread. This includes calls from debugging libraries such as redux-logger, so make sure to remove them before bundling. You can also use this babel plugin that removes all the console.* calls. You need to install it first with npm i babel-plugin-transform-remove-console --save-dev, and then edit the .babelrc file under your project directory like this:

-
{
-  "env": {
-    "production": {
-      "plugins": ["transform-remove-console"]
-    }
-  }
-}
+
{
+  "env": {
+    "production": {
+      "plugins": ["transform-remove-console"]
+    }
+  }
+}
 

 
This will automatically remove all console.* calls in the release (production) versions of your project.

 
ListView initial rendering is too slow or scroll performance is bad for large lists

 
Use the new FlatList or SectionList component instead. Besides simplifying the API, the new list components also have significant performance enhancements, the main one being nearly constant memory usage for any number of rows.

-
If your FlatList is rendering slow, be sure that you've implemented getItemLayout to optimize rendering speed by skipping measurement of the rendered items.

+
If your FlatList is rendering slow, be sure that you've implemented getItemLayout to optimize rendering speed by skipping measurement of the rendered items.

 
JS FPS plunges when re-rendering a view that hardly changes

 
If you are using a ListView, you must provide a rowHasChanged function that can reduce a lot of work by quickly determining whether or not a row needs to be re-rendered. If you are using immutable data structures, this would only need to be a reference equality check.

 
Similarly, you can implement shouldComponentUpdate and indicate the exact conditions under which you would like the component to re-render. If you write pure components (where the return value of the render function is entirely dependent on props and state), you can leverage PureComponent to do this for you. Once again, immutable data structures are useful to keep this fast -- if you have to do a deep comparison of a large list of objects, it may be that re-rendering your entire component would be quicker, and it would certainly require less code.

diff --git a/img/homepage/cross-platform.svg b/img/homepage/cross-platform.svg
index 0350af538d2..366765d5ea1 100644
--- a/img/homepage/cross-platform.svg
+++ b/img/homepage/cross-platform.svg
@@ -1 +1 @@
-App.jsxHeader.ios.jsxHeader.android.jsxBody.jsxImageTextTextTextTextText
\ No newline at end of file
+App.jsHeader.ios.jsHeader.android.jsBody.jsImageTextTextTextTextText
\ No newline at end of file