Updated docs for next

releases/next/docs/flatlist.html

@@ -81,7 +81,8 @@ any of your <code>renderItem</code>, Header, Footer, etc. functions depend on an
 you know the height of items a priori. <code>getItemLayout</code> is the most efficient, and is easy to
 use if you have fixed height items, for example:</p><div class="prism language-javascript">getItemLayout<span class="token operator">=</span><span class="token punctuation">{</span><span class="token punctuation">(</span>data<span class="token punctuation">,</span> index<span class="token punctuation">)</span> <span class="token operator">=&gt;</span> <span class="token punctuation">(</span>
   <span class="token punctuation">{</span>length<span class="token punctuation">:</span> ITEM_HEIGHT<span class="token punctuation">,</span> offset<span class="token punctuation">:</span> ITEM_HEIGHT <span class="token operator">*</span> index<span class="token punctuation">,</span> index<span class="token punctuation">}</span>
-<span class="token punctuation">)</span><span class="token punctuation">}</span></div><p>Remember to include separator length (height or width) in your offset calculation if you
+<span class="token punctuation">)</span><span class="token punctuation">}</span></div><p>Adding <code>getItemLayout</code> can be a great performance boost for lists of several hundred items.
+Remember to include separator length (height or width) in your offset calculation if you
 specify <code>ItemSeparatorComponent</code>.</p></div></div><div class="prop"><h4 class="propTitle"><a class="anchor" name="horizontal"></a>horizontal?: <span class="propType"><span>?boolean</span></span> <a class="hash-link" href="docs/flatlist.html#horizontal">#</a></h4><div><p>If true, renders items next to each other horizontally instead of stacked vertically.</p></div></div><div class="prop"><h4 class="propTitle"><a class="anchor" name="initialnumtorender"></a>initialNumToRender: <span class="propType">number</span> <a class="hash-link" href="docs/flatlist.html#initialnumtorender">#</a></h4><div><p>How many items to render in the initial batch. This should be enough to fill the screen but not
 much more. Note these items will never be unmounted as part of the windowed rendering in order
 to improve perceived performance of scroll-to-top actions.</p></div></div><div class="prop"><h4 class="propTitle"><a class="anchor" name="initialscrollindex"></a>initialScrollIndex?: <span class="propType"><span>?number</span></span> <a class="hash-link" href="docs/flatlist.html#initialscrollindex">#</a></h4><div><p>Instead of starting at the top with the first item, start at <code>initialScrollIndex</code>. This

releases/next/docs/performance.html

@@ -37,7 +37,9 @@ You can also use this <a href="https://babeljs.io/docs/plugins/transform-remove-
   <span class="token punctuation">}</span>
 <span class="token punctuation">}</span></div><p>This will automatically remove all <code>console.*</code> calls in the release (production) versions of your project.</p><h3><a class="anchor" name="listview-initial-rendering-is-too-slow-or-scroll-performance-is-bad-for-large-lists"></a><code>ListView</code> initial rendering is too slow or scroll performance is bad for large lists <a class="hash-link" href="docs/performance.html#listview-initial-rendering-is-too-slow-or-scroll-performance-is-bad-for-large-lists">#</a></h3><p>Use the new <a href="docs/flatlist.html" target="_blank"><code>FlatList</code></a> or <a href="docs/sectionlist.html" target="_blank"><code>SectionList</code></a> 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.</p><h3><a class="anchor" name="js-fps-plunges-when-re-rendering-a-view-that-hardly-changes"></a>JS FPS plunges when re-rendering a view that hardly changes <a class="hash-link" href="docs/performance.html#js-fps-plunges-when-re-rendering-a-view-that-hardly-changes">#</a></h3><p>If you are using a ListView, you must provide a <code>rowHasChanged</code> 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 be as simple as a reference equality check.</p><p>Similarly, you can implement <code>shouldComponentUpdate</code> 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 PureRenderMixin 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.</p><h3><a class="anchor" name="dropping-js-thread-fps-because-of-doing-a-lot-of-work-on-the-javascript-thread-at-the-same-time"></a>Dropping JS thread FPS because of doing a lot of work on the JavaScript thread at the same time <a class="hash-link" href="docs/performance.html#dropping-js-thread-fps-because-of-doing-a-lot-of-work-on-the-javascript-thread-at-the-same-time">#</a></h3><p>&quot;Slow Navigator transitions&quot; is the most common manifestation of this, but there are other times this can happen. Using InteractionManager can be a good approach, but if the user experience cost is too high to delay work during an animation, then you might want to consider LayoutAnimation.</p><p>The Animated API currently calculates each keyframe on-demand on the JavaScript thread unless you <a href="https://facebook.github.io/react-native/blog/2017/02/14/using-native-driver-for-animated.html#how-do-i-use-this-in-my-app" target="_blank">set <code>useNativeDriver: true</code></a>, while LayoutAnimation leverages Core Animation and is unaffected by JS thread and main thread frame drops.</p><p>One case where I have used this is for animating in a modal (sliding down from top and fading in a translucent overlay) while initializing and perhaps receiving responses for several network requests, rendering the contents of the modal, and updating the view where the modal was opened from. See the Animations guide for more information about how to use LayoutAnimation.</p><p>Caveats:</p><ul><li>LayoutAnimation only works for fire-and-forget animations (&quot;static&quot; animations) -- if it must be interruptible, you will need to use <code>Animated</code>.</li></ul><h3><a class="anchor" name="moving-a-view-on-the-screen-scrolling-translating-rotating-drops-ui-thread-fps"></a>Moving a view on the screen (scrolling, translating, rotating) drops UI thread FPS <a class="hash-link" href="docs/performance.html#moving-a-view-on-the-screen-scrolling-translating-rotating-drops-ui-thread-fps">#</a></h3><p>This is especially true when you have text with a transparent background positioned on top of an image,
+the main one being nearly constant memory usage for any number of rows.</p><p>If your <a href="docs/flatlist.html" target="_blank"><code>FlatList</code></a> is rendering slow, be sure that you&#x27;ve implemented
+<a href="https://facebook.github.io/react-native/docs/flatlist.html#getitemlayout" target="_blank"><code>getItemLayout</code></a> to
+optimize rendering speed by skipping measurement of the rendered items.</p><h3><a class="anchor" name="js-fps-plunges-when-re-rendering-a-view-that-hardly-changes"></a>JS FPS plunges when re-rendering a view that hardly changes <a class="hash-link" href="docs/performance.html#js-fps-plunges-when-re-rendering-a-view-that-hardly-changes">#</a></h3><p>If you are using a ListView, you must provide a <code>rowHasChanged</code> 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 be as simple as a reference equality check.</p><p>Similarly, you can implement <code>shouldComponentUpdate</code> 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 PureRenderMixin 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.</p><h3><a class="anchor" name="dropping-js-thread-fps-because-of-doing-a-lot-of-work-on-the-javascript-thread-at-the-same-time"></a>Dropping JS thread FPS because of doing a lot of work on the JavaScript thread at the same time <a class="hash-link" href="docs/performance.html#dropping-js-thread-fps-because-of-doing-a-lot-of-work-on-the-javascript-thread-at-the-same-time">#</a></h3><p>&quot;Slow Navigator transitions&quot; is the most common manifestation of this, but there are other times this can happen. Using InteractionManager can be a good approach, but if the user experience cost is too high to delay work during an animation, then you might want to consider LayoutAnimation.</p><p>The Animated API currently calculates each keyframe on-demand on the JavaScript thread unless you <a href="https://facebook.github.io/react-native/blog/2017/02/14/using-native-driver-for-animated.html#how-do-i-use-this-in-my-app" target="_blank">set <code>useNativeDriver: true</code></a>, while LayoutAnimation leverages Core Animation and is unaffected by JS thread and main thread frame drops.</p><p>One case where I have used this is for animating in a modal (sliding down from top and fading in a translucent overlay) while initializing and perhaps receiving responses for several network requests, rendering the contents of the modal, and updating the view where the modal was opened from. See the Animations guide for more information about how to use LayoutAnimation.</p><p>Caveats:</p><ul><li>LayoutAnimation only works for fire-and-forget animations (&quot;static&quot; animations) -- if it must be interruptible, you will need to use <code>Animated</code>.</li></ul><h3><a class="anchor" name="moving-a-view-on-the-screen-scrolling-translating-rotating-drops-ui-thread-fps"></a>Moving a view on the screen (scrolling, translating, rotating) drops UI thread FPS <a class="hash-link" href="docs/performance.html#moving-a-view-on-the-screen-scrolling-translating-rotating-drops-ui-thread-fps">#</a></h3><p>This is especially true when you have text with a transparent background positioned on top of an image,
 or any other situation where alpha compositing would be required to re-draw the view on each frame.
 You will find that enabling <code>shouldRasterizeIOS</code> or <code>renderToHardwareTextureAndroid</code> can help with this significantly.</p><p>Be careful not to overuse this or your memory usage could go through the roof.
 Profile your performance and memory usage when using these props.