Wordsmithing

content/blog/2018-02-07-update-on-async-rendering.md

@@ -27,7 +27,7 @@ We have been fine-tuning the performance of React with every new release. Howeve
 
 We found that asynchronous rendering can help in several ways. For example:
 
-1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This leads to a lot of boilerplate code managing data fetching and displaying the loading states. It can also lead to a "cascade of spinners" as the data loads, causing DOM reflows and janky user experience. We'd like to make it easier for product developers to express asynchronous dependencies of components- keeping the old UI "alive" for a certain period while the new UI is not "ready" yet. React could render this new UI in the background and provide a declarative way to show a loading indicator if it takes more than a second.
+1. As users navigate within an app, newly displayed components often have asynchronous dependencies (including data, images, and code splitting). This leads to a lot of boilerplate code managing data fetching and displaying the loading states. It can also lead to a "cascade of spinners" as the data loads, causing DOM reflows and janky user experience. We'd like to make it easier for product developers to express asynchronous dependencies of components. React could keep the old UI "alive" and interactive for a certain period while the updated UI is not ready yet, and provide a declarative way to show a loading indicator if it takes more than a second.
 2. Fast updates within a short timeframe often cause jank because React processes each update individually. We'd like to automatically "combine" updates within a few hundred milliseconds when possible so that there is less re-rendering.
 3. Some updates are inherently less important than others. For example, if you're writing a live-updating search filter input like [this](https://zeit.co/blog/domains-search-web#asynchronous-rendering), it is essential that the input is updated immediately (within a few milliseconds). Re-rendering the result list can be done later, and should not block the thread or cause stutter when typing. It would be nice if React had a way to mark the latter updates as having a lower priority. (Note that even debouncing the input doesn't help because if the rendering is synchronous—like in React today—a keystroke can't interrupt the rendering if it already started. Asynchronous rendering solves this by splitting rendering into small chunks that can be paused and later restarted.)
 4. For UI elements like hidden popups and tabs, we'd like to be able to start pre-rendering their content when the browser isn't busy. This way, they can appear instantaneously in response to a later user interaction. However, we don't want to make the initial rendering slower, so it's essential to render such elements lazily ([when the browser is idle](https://developers.google.com/web/updates/2015/08/using-requestidlecallback)).

examples/update-on-async-rendering/initializing-state-after.js

@@ -2,7 +2,7 @@
 class ExampleComponent extends React.Component {
   // highlight-range{1-4}
   state = {
-    isScrollingDown: false,
-    lastRow: this.props.currentRow,
+    currentColor: this.props.defaultColor,
+    palette: 'rgb'
   };
 }

examples/update-on-async-rendering/initializing-state-before.js

@@ -5,8 +5,8 @@ class ExampleComponent extends React.Component {
   // highlight-range{1-6}
   componentWillMount() {
     this.setState({
-      isScrollingDown: false,
-      lastRow: this.props.currentRow,
+      currentColor: this.props.defaultColor,
+      palette: 'rgb'
     });
   }
-}
+}