Umbrella: 16.3 and 16.4 releases

[acdlite]

16.3

• New context API
  • Add context API to test renderer ContextConsumer and ContextProvider in react-test-renderer #12150
  • Add context API to shallow renderer (if it even makes sense?)
  • Mark private fields as private Prefix private API fields on the context object #12203
  • Context consumer/provider should bailout if props did not change Context.Consumer unexpectedly updates each time one of its child components call setState #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: Expose persistent reconciler to custom renderers #12156
• Fix fragment support in test renderer Fix fragment and portal handling in toTree() #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.

[pshrmn]

Does it make sense to have shallow rendering with the new context API? I see a couple of issues with that.

1. A <Consumer> has to be rendered inside of a <Provider>. Can this be simulated through options the way that the old context is?
2. Unless I'm mistaken, the children function passed to a <Consumer> won't actually be called during a shallow render, which means you can't test its output.

[gaearon]

Yeah, it's not clear to me if this makes sense or not either.

[WhoAteDaCake]

I am out of the loop, why is componentWillMount bad?

[gaearon]

Please wait for the blog post. It'll explain everything. :-)

[AlicanC]

Is it too late to ask for s/getDerivedStateFromProps/deriveStateFromProps/?

[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.

[kvolkovich-sc]

Guys, these breaking changes are looks like a waste of thousands man/hours for big projects.

What is a real benefit of these changes? I hope you know what you're doing)

[gaearon]

There are no breaking changes here (in React 16.3, 16.4, or another minor 16.x release). React has always respected semver, and never introduced breaking changes to public APIs in minor versions.

What are you referring to?

Our major releases (like upcoming 17 that is months away) always had breaking changes. That’s literally the reason for doing major releases. We have 50 thousand React components at Facebook so we don’t make any breaking changes without a good migration path that works at scale.

[kvolkovich-sc]

@gaearon, we are waiting for a blog post that will "explain everything. :-)" and reassure us. 😌

[blling]

@kvolkovich-sc
There must be sacrifices for progress

[gaearon]

@kvolkovich-sc The blog post comes out together with the release. You can see the checklist for things to do before the release right above in this thread. I don't see the sense in adding to the pressure or creating the FUD in this thread.

[gaearon]

Locking this so we can focus on getting the release out together with the blog post.