New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Umbrella: 16.3 and 16.4 releases #12152

Closed
acdlite opened this Issue Feb 4, 2018 · 15 comments

Comments

Projects
None yet
9 participants
@acdlite
Copy link
Member

acdlite commented Feb 4, 2018

16.3

  • New context API
    • Add context API to test renderer #12150
    • Add context API to shallow renderer (if it even makes sense?)
    • Mark private fields as private #12203
    • Context consumer/provider should bailout if props did not change #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: #12156
  • Fix fragment support in test renderer #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

This comment has been minimized.

Copy link

pshrmn commented Feb 5, 2018

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

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

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

@WhoAteDaCake

This comment has been minimized.

Copy link

WhoAteDaCake commented Feb 5, 2018

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

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

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

@AlicanC

This comment has been minimized.

Copy link

AlicanC commented Feb 5, 2018

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

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

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

This comment has been minimized.

Copy link

kvolkovich-sc commented Feb 5, 2018

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

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

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

This comment has been minimized.

Copy link

kvolkovich-sc commented Feb 5, 2018

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

@blling

This comment has been minimized.

Copy link

blling commented Feb 5, 2018

@kvolkovich-sc
There must be sacrifices for progress

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

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

@facebook facebook locked and limited conversation to collaborators Feb 5, 2018

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

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

@jquense

This comment has been minimized.

Copy link
Collaborator

jquense commented Feb 5, 2018

We should include the Enzyme folks in the shallow context discussion, since that will almost certainly affect the public API of shallow, I'm not sure if it can be worked around without support in the renderer tho.

@gaearon

This comment has been minimized.

Copy link
Member

gaearon commented Feb 5, 2018

Makes sense. Want to reach out to them?

@aweary

This comment has been minimized.

Copy link
Member

aweary commented Feb 5, 2018

Enzyme currently provides an API for setting legacy context when shallow rendering. Its reasonable to add a way to mock the Provider as well. I might expect the shallow renderer to act as if the Consumer components didn't exist. So the tree would render at the same depth it would render if there were no context providers, since there's no real reason to assert on Consumers directly

@gaearon gaearon closed this May 15, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.