Umbrella: 16.3 and 16.4 releases

16.3

• New context API
  • Add context API to test renderer https://github.com/facebook/react/issues/12150
  • Add context API to shallow renderer (if it even makes sense?)
  • Mark private fields as private https://github.com/facebook/react/issues/12203
  • Context consumer/provider should bailout if props did not change https://github.com/facebook/react/issues/12218
• getDerivedStateFromProps
  • Looks like the wording of this warning might need to be updated to reflect it actually won’t work and not just a recommendation
• UNSAFE-prefixed versions of componentWillMount and componentWillUpdate
• StrictMode
  • Fires deprecation warnings for componentWillMount, componentWillUpdate, componentWillReceiveProps.
• unstable_AsyncMode
  • Enables async-by-default updates.
  • Also enables strict mode.
• Changes related to async mode:
  • Update scheduling:
    • Interactive updates
      • Async, expires within ~1 second. If a subsequent interactive event is fired before an earlier one has flushed, the earlier one is synchronously flushed before processing the incoming one.
      • Used for any event that is the result of a discrete user interaction. In other words, interactive events are events that cannot be debounced without affecting the terminal state. So a click event is interactive, but a scroll event is not.
    • Controlled updates
      • Sync-ish. Effectively the same as using unstable_batchedUpdates in synchronous mode. Updates are flushed before React yields back to the browser.
      • Used for controlled components, where the state of the DOM must always be in sync with React’s internal state.
    • Deferred updates
      • Default for updates outside a React lifecycle or event handler: setTimeout, promise handlers, etc.
  • unstable_createRoot
    • Only useful for pre-rendering via createBatch. Not quite ready to make this API stable.
    • Also enables async-mode for all children and the root.
  • unstable_flushControlled
    • Only useful for things like Draft that need to wrap event handlers.
  • Confirm unstable_deferredUpdates et al work when nested inside a lifecycle or other priority-changing function.
• Expose persistent mode via react-reconciler
  • Use a separate entry point: react-reconciler/persistent, PR: https://github.com/facebook/react/pull/12156
• Fix fragment support in test renderer https://github.com/facebook/react/pull/12154
• Revert the deprecation of injecting custom event plugins (@necolas will do that) because we’re not ready to commit to providing another migration path for RNW

16.4

• Deprecate componentWillMount, componentWillUpdate, and componentWillReceiveProps, even outside strict mode.
  • They will keep working, but with a warning. You can add the UNSAFE_ prefix if you want to keep using them.
• Deprecate legacy context API (?)
  • Possible migration strategy: implement the legacy API on top of the new API and extract it into a separate package, like create-react-class and prop-types.
• Revert deprecation of injecting event plugins

A Far Future Major Version

• Remove deprecated APIs
  • Legacy context API (assuming we deprecate this in 16.x minor)
  • componentWillReceiveProps, componentWillUpdate, componentWillMount
• Strict mode everywhere
  • Presumably we’ll have added more warnings to strict mode by this point

Chose not to include in 16.3, but may include in 16.4 or beyond:

• New component API. We’re holding off on this until we’re closer to “feature complete,” a phrase which here means “having implemented async rendering and bytecode compilation.”
• Static version of render method. It would take lots of effort to migrate, mostly because of class instance methods used as event handlers. The migration effort may not be worth it if we eventually introduce a new component API that replaces classes.
• Stable version of unstable_batchedUpdates. We really should have made this stable a while ago, as it’s clearly useful in synchronous mode. However, in asynchronous mode, it’s effectively a no-op, so it would be weird to ask everyone to migrate to a new API, only to remove it in an upcoming release.
• Stable version of unstable_AsyncMode. It’s probably ready to be used in production, in a limited capacity, but we’re holding off until we’ve tested it more internally. Tentative plan is to make this stable in 16.4.
• Automatically opt error boundary children into strict mode. Technically, they should be strict mode resilient, but in many apps, this would effectively opt all components into strict mode, since the recommendation is to always have an error boundary at the top of the tree.

[gaearon]

Yeah. 😛 Please follow the RFCs to discuss early: https://github.com/reactjs/rfcs

We also intentionally added get* there because this API is rarely needed (so you shouldn’t type it often) and it should be obvious you can’t setState in it.

[gaearon]

Please wait for the blog post. It’ll explain everything. 😃