React 16 Umbrella ☂️ (and 15.5) #8854

gaearon · 2017-01-24T00:46:38Z

This list might change, just putting it out there as the first draft.
Posting these together since they're related, and we don't plan more 15.x releases after 15.5 anyway.

To put these changes in context, we have a few goals:

(Click to show)

For the past several months, we have been working on a rewrite of React codenamed “Fiber”. Initially, it won’t affect public API, but it brings several new features (like Add fragment API to allow returning multiple components from render #2127 and Error boundaries: Recover from errors thrown in render #2461). Fiber gives us a solid foundation to improve React core in numerous ways. We’ll be talking more about it soon, and we intend to ship it with React 16 by default.
To reduce the bundle size, we need to remove the APIs that we don't recommend, such as createClass and React.DOM.* helpers. We intend to warn once about their usage so that you can start removing dependencies on them. They will still be available as separate packages, but we will exclude them from the default build of React 16.
We would like to have more control over the bundles so that we can better optimize them. This is why we are considering switching to flat bundles (and thus removing access to React internals in react/lib/* and react-dom/lib/*) in React 16. This will also mean faster compile times by default for users of Webpack and other bundlers, and faster server-side rendering performance.

Here’s a speculative list of changes we think of doing in these releases:

Past Releases

I’ve moved these to the end of this post.

16 Final

TODO: Add any bugs discovered while testing RC.

16 Wishlist

Fix hot reloading in RN (probably needs unstable_forceUpdateDeep() and then change https://github.com/gaearon/react-deep-force-update to use it)
Show a better message for missing React (Show a better message if React is not loaded #10406)
Make sure we offer a way of canceling setState updater form (https://twitter.com/nishb1/status/852542873803345920) (@gaearon will follow up)
Remove Stack and compat code
Add support to Enzyme for Fiber (Refactor enzyme to use Adapters, initial React 16 support enzymejs/enzyme#1007)

Past Releases

15.5

(Click to show)

15.6

See #9398.

16 Alpha

(Click to show)

16 Beta

(Click to show)

16 RC

(Click to show)

The text was updated successfully, but these errors were encountered:

aweary · 2017-01-24T00:53:32Z

ReactDOM fixes, if @jquense @nhunzaker @aweary want to release any.

I think at least #8575 and #7359 should be included in 15.5. They're both close to being merged.

nhunzaker · 2017-01-24T01:04:48Z

@jquense we probably want to merge yours first (#8575). #7359 relies on ChangeEventPlugin to keep the value attribute in sync with the value property. We'll need to re-evaluate #7359 with those changes.

jamiebuilds · 2017-01-24T01:26:41Z

React.createClass will be moved to a separate package

React.createFactory will be moved to a separate package

React.DOM.* factories will be moved to a separate package

All these new packages, maybe you need a tool for managing so many packages in a single repo... 😉

sophiebits · 2017-01-24T01:31:55Z

As long as it doesn't make our UMD builds harder I'm on board with lerna. Someone want to send a PR?

gaearon · 2017-01-24T01:33:28Z

Pretty sure we've reached peak harder and it's downhill from there.

jamiebuilds · 2017-01-24T01:37:46Z

@gaearon Challenge accepted.

@spicyj jk I won't make it harder, I'll throw something together for you

tizmagik · 2017-01-24T02:09:53Z

This is awesome! Excited about what's ahead in React 16. Also glad I won't have to manually create a minified build of React for server render. 😅

Curious, any idea about how much larger the bundle is with React Fiber?

klzns · 2017-01-24T02:13:44Z

Why is this scratched?

Make setState async by default.
Remove the attribute whitelist.
Stateful functional components.
New context API.

If it's just a stylistic choice, it's confusing. It's like a double negative hehe

jquense · 2017-01-24T03:26:55Z

Ya! look great y'all. one thought related to flat bundles. it's harder to write certain types of tooling without access to internal apis. Specifically thinking about test libs, the few I maintain invariably need to touch a bunch of internal apis when test utils fall short. it's a bit of a niche use case tho asandthe cost of using those Apis is well understood and aren't used in production apps

quantizor · 2017-01-24T03:29:51Z

If you guys do want to switch to lerna, I've been working on rollup scripting to make flat files of lerna packages. Would be happy to help out.

gaearon · 2017-01-24T07:10:43Z

Curious, any idea about how much larger the bundle is with React Fiber?

Right now it's roughly the same size while implementing more features (async scheduling, error boundaries, fragments, portals). We haven't worked on optimizing its size so I think we can reduce it further too. We'll likely do so after the initial release.

Another promising (IMO) area is Fiber's support for custom renderers. If ReactDOM's tradeoffs don't match what your product needs, it should be much easier to create a custom DOM renderer that, for example, doesn't ship with the synthetic event system. Fiber makes custom renderers way easier to create, while giving you all component features out of the box.

Hurtak · 2017-01-24T09:31:52Z

'Stateful functional components' is there some issue where I can read more about this?

swernerx · 2017-01-24T09:43:24Z

When you go the flat bundle route - which I definitely appreciate - it would be awesome to offer a modern bundle for Node v6 / ES2015 capable browsers, too.

I did some work on this topic in http://npmjs.com/package/prepublish - which effectively produces flat bundles for different output scenarios. Basically a configured wrapper around Rollup/Babel/Buble.

I also thought of adding specific "modern" entries to the package.json so that bundles like Webpack can make use of this e.g. main:modern or module:modern. I think something like this would be definitely interesting for React (especially in context of SSR apps where you can target Node >= v6).

nakamorichi · 2017-01-24T10:18:55Z

Agree with @swernerx . It's about time to migrate to ES6.

gaearon · 2017-01-24T10:23:23Z

@swernerx This is an interesting direction and we may explore it in the future. Right now the browser support for ES6 is increasing but many features are sufficiently slower than ES5 counterparts, just because nobody had time to optimize it yet. I know V8 team is hard at work fixing this, and I’d rather look into it again after evergreen browsers are mostly fast when using ES6.

gaearon · 2017-01-24T10:25:19Z

'Stateful functional components' is there some issue where I can read more about this?

No specific issue AFAIK. There are some old ideas in this repo if you’re interested, but they’re just that, ideas. There are numerous reasons we’re interested in having stateful functional components, I listed some here.

dtinth · 2017-01-24T10:34:39Z

Concerning the “flat bundles,” it would be great if the internals are still exposed one way or the other, because we at Taskworld sometimes monkey-patched React internals from userland code to have more fine-grained error messages and performance measurement.

What we did is we hooked into React’s internals and added some instrumenting code like this:

Show code

  const ReactReconciler = require('react/lib/ReactReconciler')

  ReactReconciler.mountComponent = ((mountComponent) => function (internalInstance) {
    enter('React mount ' + describeInstance(internalInstance))
    try { return mountComponent.apply(this, arguments) } finally { exit() }
  })(ReactReconciler.mountComponent)

  ReactReconciler.receiveComponent = ((receiveComponent) => function (internalInstance) {
    enter('React update ' + describeInstance(internalInstance))
    try { return receiveComponent.apply(this, arguments) } finally { exit() }
  })(ReactReconciler.receiveComponent)

  ReactReconciler.unmountComponent = ((unmountComponent) => function (internalInstance) {
    enter('React unmount ' + describeInstance(internalInstance))
    try { return unmountComponent.apply(this, arguments) } finally { exit() }
  })(ReactReconciler.unmountComponent)

…

We also hooked into Redux and Reselect in similar ways for a unified development experience.

I know that this isn’t supported and internal APIs may break in any release (especially with Fiber coming), but unsupported is better than impossible 😄.

gaearon · 2017-01-24T10:51:49Z

we at Taskworld sometimes monkey-patched React internals from userland code to have more fine-grained error messages

This is supported by error boundaries in Fiber.

and performance measurement.

You can use ReactPerf for that.

I know that this isn’t supported and internal APIs may break in any release (especially with Fiber coming), but unsupported is better than impossible 😄.

Even better, let’s discuss the use cases and come up with supported APIs. 😉

swernerx · 2017-01-24T10:52:38Z

@gaearon It's about offering such a package format for modern clients (in parallel to the classic build - which is what the prepublish tool mentioned does). In the end React does not decide on the processing/bundling/output of the application. But if you transpile stuff you make the original ES6 code unaccessible for any user who wants to deploy for modern node or embedded browsers only.

swernerx · 2017-01-24T10:53:47Z

@gaearon "main" and "module" should always point to the ES5 bundles with either commonjs or esmodule outputs. But we are free to offer an alternative modern build keeping ES2015 stuff intact.

MilosRasic · 2017-01-24T10:57:41Z

Excuse my ignorance, but does removal of createMixin mean that all packages that rely on mixins will stop working until dependants switch to a HOC solution or will they be able to quickly switch to an alternate way to provide old-style mixins?

gaearon · 2017-01-24T11:00:54Z

Excuse my ignorance, but does removal of createMixin mean that all packages that rely on mixins will stop working until dependants switch to a HOC solution or will they be able to quickly switch to an alternate way to provide old-style mixins?

createMixin implementation looks like this:

function createMixin(mixin) {
  return mixin;
}

It was never documented, and only appeared in the API because we thought we might want to validate mixins in the future. Packages that somehow found out about it and started using it can just remove the createMixin call and use the mixin directly.

Most packages providing mixins don’t use createMixin. For those that do, this is a one-line change: just removing the useless function call.

It's about offering such a package format for modern clients (in parallel to the classic build - which is what the prepublish tool mentioned does)

Yes, I understand this. What I’m saying is if we offer this build, people will use it, and if performance is suboptimal, they will blame React. So we will wait until ES6 features are actually fast before providing a build that does that.

nakamorichi · 2017-01-24T11:12:25Z

@gaearon Migration to ES6 can be done in iterations, e.g., first convert all vars to either let or const, then other features that are supported without performance issues.

Also, there are two issues here: (1) syntax of the source code, and (2) syntax of the bundle. Is there a reason for not migrating the source to the latest standard - ES7/ES2016 - with the possibility of using staged features if deemed useful enough?

Syntax of the bundle is a totally separate issue, as the syntax of the bundle (or bundles) can be decided during the build step. I think it would be awesome to have separate bundles for each relevant standard, but I'm not sure how to achieve this in practice, or whether this can be achieved without unreasonable amount of work. Nevertheless, ES6 is here to stay, and the project ought to provide bundle targeting it, which naturally first requires converting the source to utilize its features.

gaearon · 2017-01-24T11:23:08Z

We are pragmatic in choosing both source and target languages, and are driven by pragmatic needs.

Migration to ES6 can be done in iterations, e.g., first convert all vars to either let or const, then other features that are supported without performance issues.

For the target bundle, what exactly would that accomplish? There are no benefits to the end users in this case, and there are downsides (less browser support, more fragmentation and potential surface area for bugs).

Is there a reason for not migrating the source to the latest standard - ES7/ES2016 - with the possibility of using staged features if deemed useful enough?

We are using new features in newly written code. There is very little benefit, in our opinion, to rewrite existing code with new features since this also introduces a risk of new bugs. It’s a nice way to ramp up contributors, but as noted in this issue, we have already rewritten most of React so it doesn’t make sense to me to convert the old code now.

zalmoxisus · 2017-01-24T11:47:19Z

@gaearon

Even better, let’s discuss the use cases and come up with supported APIs.

It would be great to have an API to detect if an object is a Synthetic Event. For Redux, usually users are passing events as action payloads (which also redux-actions does), even when not using them. It breaks the ability to access them while sending to the monitors. A simple solution was:

import SyntheticEvent from 'react/lib/SyntheticEvent';
// ...

const store = createStore(rootReducer, window.__REDUX_DEVTOOLS_EXTENSION__ && window.__REDUX_DEVTOOLS_EXTENSION__({
  serialize: {
    replacer: (key, value) => {
      if (value && value instanceof SyntheticEvent) return '[Event]';
      return value;
    }
  }
}));

Though maybe we should just encourage using event.persist when not providing event data explicitly.

gaearon · 2017-01-24T11:49:57Z

Though maybe we should just encourage using event.persist when not providing event data explecitely.

This is the solution here.

nakamorichi · 2017-01-24T12:13:57Z

@gaearon I totally understand if code that may soon be deprecated is not rewritten, but is it really a good idea to, for example, continue using two module syntaxes side-by-side in newly written code? I see some source files even combining both. For parts that are necessary for supporting Node, using Node's module syntax is of course understandable. Personally I feel quite strongly about unnecessarily mixing two competing module handling mechanisms - particularly in newly written code, and particularly when talking about a standard- and a non-standard one.

One point, not sure if actually relevant, came to my mind: React is one of the "hottest" libraries out there in the JavaScript world, and if React decided to fully utilize the latest standardized ES features (preferably with strict style guidelines), this might incentivize browser manufacturers to hasten their optimization efforts. React could show way for, not only other UI libraries out there, but for the whole JavaScript ecosystem. Maybe slightly optimistic, but 😺

gaearon · 2017-01-24T12:30:24Z

using two module syntaxes side-by-side in newly written code? I see some source files even combining both.

We are using CommonJS exclusively right now (mostly due to Facebook build pipeline limitations). I think you might be confusing Flow's import type syntax with ES modules.

nakamorichi · 2017-01-24T12:57:57Z

Oh, haven't used Flow so that kind of syntax was new for me.

**what is the change?:** We add a flag to the container of a 'portal' in the 'commit work' phase in Fiber. This is right before we call `appendChildToContainer`. **why make this change?:** - Sometimes people call `ReactDOM.render(... container)`, then manually clear the content of the `container`, and then try to call another `ReactDOM.render(... container)`. - This leads to cryptic errors or silent failure because we hold a reference to the node that was rendered the first time, and expect it to still be inside the container. - We added a warning for this issue in `renderSubtreeIntoContainer`, but when a component renders something returned by `ReactDOM.unstable_createPortal(<Component />, portalContainer);`, then the child is inside the `portalContainer` and not the `container, but that is valid and we want to skip warning in that case. Inside `renderSubtreeIntoContainer` we don't have the info to determine if a child was rendered into a `portalContainer` or a `container`, and adding this flag lets us figure that out and skip the warning. We originally added the flag in the call to `ReactDOM.unstable_createPortal` but that seemed like a method that should be "pure" and free of side-effects. This commit moves the flag-adding to happen when we mount the portal component. **test plan:** `yarn test` **issue:** facebook#8854

**what is the change?:** This is awful. :( I'm not sure how else to let Flow know that we expect that this might be a sort of `DOMContainer` type and not just a normal `Node` type. To at least make the type information clear we added a comment. **why make this change?:** To get `flow` passing. Looks like we have `any` types sprinkled throughout this file. phooey. :( **test plan:** `yarn flow` **issue:** facebook#8854

**what is the change?:** We want to ignore portals when firing a certain warning. This allows us to get the host instance and ignore portals. Also added a new snapshot recording while fixing things. **why make this change?:** Originally we had added a flag to the DOM node which was used for rendering the portal, and then could notice and ignore children rendered into those nodes. However, it's better to just ignore portals in `DOMRenderer.findHostInstance` because - we will not ignore a non-portal second child with this approach - we meant to ignore portals in this method anyway (according to a 'TODO' comment) - this change only affects the DOM renderer, instead of changing code which is shared with RN and other renderers - we avoid adding unneeded expandos **test plan:** `yarn test` **issue:** facebook#8854

**what is the change?:** see title **why make this change?:** this is part of an old approach to detecting portals, and we have instead added a check in the `findHostInstance` method to filter out portals. **test plan:** `yarn test` **issue:** facebook#8854

**what is the change?:** We need to get host instances, but filter out portals. There is not currently a method for that. **why make this change?:** Rather than change the existing `findHostInstance` method, which would affect the behavior of the public `findDOMNode` method, we are forking. **test plan:** `yarn test` **issue:** facebook#8854

@spicyj

…10210) * RFC Add warning for rendering into container that was updated manually RFC because we still need to tidy this up and verify that all tests pass. **what is the change?:** We want to warn when users render into a container which was manually emptied or updated outside of React. This can lead to the cryptic error about not being able to remove a node, or just lead to silent failures of render. This warning should make things more clear. Note that this covers the case where the contents of the root container are manually updated, but does not cover the case where something was manually updated deeper in the tree. **why make this change?:** To maintain parity and increase clarity before releasing v16.0 beta. **test plan:** `yarn test` **issue:** #8854 last item under the '16 beta' checklist. * Add test and tweak check for rendering into manually updated container STILL TODO: figure out how to skip this warning when the component renders to a portal. Unfortunately 'ReactPortal.isPortal(children)' returns false, even in the failing test where we are rendering to a portal. **what is the change?:** - added a test for the case where we call 'ReactDOM.render' with a new container, using a key or a different type, after the contents of the first container were messed with outside of React. This case throws, and now at least there will be an informative warning along with the error. - We updated the check to compare the parent of the 'hostInstance' to the container; this seems less fragile - tweaked some comments **why make this change?:** Continue improving this to make it more final. **test plan:** `yarn test` **issue:** #8854 * Stub our `console.error` in one of the portal tests **what is the change?:** See title **why make this change?:** See comment in the code **test plan:** `yarn test` **issue:** #8854 * Skip warning in 'ReactDOMFiberEntry' when mounting to Comment node **what is the change?:** We have a warning for cases when the container doesn't match the parent which we remembered the previously rendered content being rendered into. We are skipping that warning when you render into a 'comment' node. **why make this change?:** Basically, if you render into a 'comment' node, then the parent of the comment node is the container for your rendered content. We could check for similarity there but rendering into a comment node seems like a corner case and I'd rather skip the warning without knowing more about what could happen in that case. **test plan:** `yarn test` **issue:** #8854 * Improve warning message, remove dedup check, and unmock console.error **what is the change?:** Various changes to get this closer to being finished; - Improved warning message (thanks @spicyj!!!) - Removed dedup check on warning - Remove mocking of 'console.error' in portals test **why make this change?:** - warning message improvement: communicates better with users - Remove dedup check: it wasn't important in this case - Remove mocking of 'console.error'; we don't want to ignore an inaccurate warning, even for an "unstable" feature. **test plan:** `yarn test` -> follow-up commits will fix the remaining tests **issue:** issue #8854 * Possible fix for issue of incorrect warning for portal re-render **what is the change?:** Add a property to a container which was rendered into using `ReactDOM.unstable_createPortal`. **why make this change?:** We don't want to warn for mismatching container nodes in this case - the user intentionally rendered into the portal container instead of the original container. concerns; - will this affect React Native badly? - will this add bloat to the portal code? seems small enough but not sure. **test plan:** `yarn test` **issue:** #8854 * Fix logic for checking if the host instance container is a portal **what is the change?:** When focusing on fixing the warning to not check when we are using portals, I missed checking for the existence of the host instance parent before checking if it was a portal. This adds the missing null checks. **why make this change?:** To fix a bug that the previous commit introduced. **test plan:** `yarn test` -> follow-up commits fix more of the test failures **issue:** #8854 * Clean up new tests in ReactDOMFiber-test **what is the change?:** - removed extra single quotes, downgrade double quotes to single - update expected warning message to match latest warning message - fix indentation **why make this change?:** - get tests passing - code maintainability/readability **test plan:** `yarn test` follow up commits will fix the remaining tests **issue:** #8854 * Add 'unmountComponentAtNode' call in test for reconciling pre-rendered markup **what is the change?:** We have a test that verifies React can reconcile text from pre-rendered mark-up. It tests React doing this for three strings and three empty strings. This adds a call to 'unmountComponentAtNode' between the two expectations for strings and empty strings. **why make this change?:** We now warn when someone messes with the DOM inside of a node in such a way that removes the React-rendered content. This test was doing that. I can't think of a situation where this would happen with server-side rendering without the need to call 'unmountComponentAtNode' before inserting the server-side rendered content. **test plan:** `yarn test` Only one more failing test, will fix that in the next commit. **issue:** #8854 * ran prettier * remove unused variable * run scripts/fiber/record-tests * Fix type error and improve name of portal container flag **NOTE:** I am still looking for a good place to move this flag assignment to, or a better approach. This does some intermediate fixes. **what is the change?:** - fixed flow error by allowing optional flag on a DOMContainer that indicates it was used as a portal container. - renamed the flag to something which makes more sense **why make this change?:** - get Flow passing - make this change make more sense We are still not sure about adding this flag; a follow-up diff may move it or take a different approach. **test plan:** `yarn test` **issue:** #8854 * Add flag to portalContainer on mount instead of in `createPortal` **what is the change?:** We add a flag to the container of a 'portal' in the 'commit work' phase in Fiber. This is right before we call `appendChildToContainer`. **why make this change?:** - Sometimes people call `ReactDOM.render(... container)`, then manually clear the content of the `container`, and then try to call another `ReactDOM.render(... container)`. - This leads to cryptic errors or silent failure because we hold a reference to the node that was rendered the first time, and expect it to still be inside the container. - We added a warning for this issue in `renderSubtreeIntoContainer`, but when a component renders something returned by `ReactDOM.unstable_createPortal(<Component />, portalContainer);`, then the child is inside the `portalContainer` and not the `container, but that is valid and we want to skip warning in that case. Inside `renderSubtreeIntoContainer` we don't have the info to determine if a child was rendered into a `portalContainer` or a `container`, and adding this flag lets us figure that out and skip the warning. We originally added the flag in the call to `ReactDOM.unstable_createPortal` but that seemed like a method that should be "pure" and free of side-effects. This commit moves the flag-adding to happen when we mount the portal component. **test plan:** `yarn test` **issue:** #8854 * Force an 'any' type for the `hostInstance.parentNode` in warning check **what is the change?:** This is awful. :( I'm not sure how else to let Flow know that we expect that this might be a sort of `DOMContainer` type and not just a normal `Node` type. To at least make the type information clear we added a comment. **why make this change?:** To get `flow` passing. Looks like we have `any` types sprinkled throughout this file. phooey. :( **test plan:** `yarn flow` **issue:** #8854 * Ignore portals in `DOMRenderer.findHostInstance` **what is the change?:** We want to ignore portals when firing a certain warning. This allows us to get the host instance and ignore portals. Also added a new snapshot recording while fixing things. **why make this change?:** Originally we had added a flag to the DOM node which was used for rendering the portal, and then could notice and ignore children rendered into those nodes. However, it's better to just ignore portals in `DOMRenderer.findHostInstance` because - we will not ignore a non-portal second child with this approach - we meant to ignore portals in this method anyway (according to a 'TODO' comment) - this change only affects the DOM renderer, instead of changing code which is shared with RN and other renderers - we avoid adding unneeded expandos **test plan:** `yarn test` **issue:** #8854 * Ran prettier * Remove error snapshot test I think there is a bug where an empty snapshot is treated as an 'outdated snapshot'. If I delete the obsolute snapshot, and run ReactDOMFiber-test.js it generates a new snapshot. But then when I run the test with the newly generated snapshot, it says "1 obsolete snapshot found", At some point I will file an issue with Jest. For now going to skip the snapshot generation for the error message in the new test. * Remove expando that we were adding to portal container **what is the change?:** see title **why make this change?:** this is part of an old approach to detecting portals, and we have instead added a check in the `findHostInstance` method to filter out portals. **test plan:** `yarn test` **issue:** #8854 * Fork `findHostInstance` to make `findHostInstanceWithNoPortals` **what is the change?:** We need to get host instances, but filter out portals. There is not currently a method for that. **why make this change?:** Rather than change the existing `findHostInstance` method, which would affect the behavior of the public `findDOMNode` method, we are forking. **test plan:** `yarn test` **issue:** #8854

iddan · 2017-07-25T08:45:25Z

When will I be able to return strings in component's render? As we use the 16 alpha w/ RN I thought this is already possible

gaearon · 2017-07-25T09:26:22Z

RN does not use Fiber yet. The "react" package is not very relevant here because it doesn't contain the reconciler logic. It only has helpers like createElement and Component. So it's not Fiber. We'll switch RN to Fiber some time soon but don't have an exact date.

**what is the change?:** Ran the build after updating Yarn lockfile and recorded latest build size results. **why make this change?:** Let's get an idea of bundle size at this point, when we are preparing the 16.0 RC. **test plan:** NA **issue:** facebook#8854

**what is the change?:** This just updated the error codes on the docs. For my future self, recording the steps it took to get here: - On master, run `npm run build -- --extract-errors` - Create a commit with those changes, and open a PR (facebook#10619) - Cherry-pick that commit onto 15-stable, and open a PR (facebook#10621) - Update the error codes on the `gh-pages branch` by doing the following based on docs (https://github.com/facebook/react/tree/master/docs#updating-facebookgithubioreact): - Set up a sister directory to `react` with `gh-pages` checked out, and call it `react-gh-pages` - In your `react` repo, with `15-stable` checked out and the error-codes update cherry-picked, run: `cd docs && bundle rake exec && bundle exec rake fetch_remotes && bundle exec rake release` - `cd ../react-gh-pages` and check in those changes, create a commit/PR - Manually test running the docs **why make this change?:** Even though this is just an RC, and not a final major release, we still want the docs to be as up-to-date as possible. **test plan:** Run the docs locally and make sure things work. (Flarnie will insert screenshots.) **issue:** facebook#8854

**what is the change?:** Ran the build after updating Yarn lockfile and recorded latest build size results. **why make this change?:** Let's get an idea of bundle size at this point, when we are preparing the 16.0 RC. **test plan:** NA **issue:** facebook#8854

* Update results.json **what is the change?:** Ran the build after updating Yarn lockfile and recorded latest build size results. **why make this change?:** Let's get an idea of bundle size at this point, when we are preparing the 16.0 RC. **test plan:** NA **issue:** #8854 * Update error codes https://github.com/facebook/react/tree/master/scripts/release-manager#update-the-error-codes

**what is the change?:** This just updated the error codes on the docs. For my future self, recording the steps it took to get here: - On master, run `npm run build -- --extract-errors` - Create a commit with those changes, and open a PR (#10619) - Cherry-pick that commit onto 15-stable, and open a PR (#10621) - Update the error codes on the `gh-pages branch` by doing the following based on docs (https://github.com/facebook/react/tree/master/docs#updating-facebookgithubioreact): - Set up a sister directory to `react` with `gh-pages` checked out, and call it `react-gh-pages` - In your `react` repo, with `15-stable` checked out and the error-codes update cherry-picked, run: `cd docs && bundle rake exec && bundle exec rake fetch_remotes && bundle exec rake release` - `cd ../react-gh-pages` and check in those changes, create a commit/PR - Manually test running the docs **why make this change?:** Even though this is just an RC, and not a final major release, we still want the docs to be as up-to-date as possible. **test plan:** Run the docs locally and make sure things work. (Flarnie will insert screenshots.) **issue:** #8854

* Update results.json **what is the change?:** Ran the build after updating Yarn lockfile and recorded latest build size results. **why make this change?:** Let's get an idea of bundle size at this point, when we are preparing the 16.0 RC. **test plan:** NA **issue:** facebook#8854 * Update error codes https://github.com/facebook/react/tree/master/scripts/release-manager#update-the-error-codes

**what is the change?:** Added an 'unreleased' section to the changelog with info from facebook#10294 **why make this change?:** To get things set for the 16.0 release. **test plan:** Visual inspection **issue:** facebook#8854

**what is the change?:** In response to helpful code review - - Add mention of dependency on `requestAnimationFrame` and need to polyfill that as well as `Map` and `Set` - Remove "New helpful warnings" section; it was incomplete, and there are so many new and updated warnings that it might not be reasonable to cover them in the changelog. **why make this change?:** Accuracy **test plan:** Visual inspection **issue:** issue facebook#8854

@gaearon

**what is the change?:** Thanks to the kind code review comments of @gaearon and @nhunzaker we have - removed the non-deterministic bold styling on some bullet points - improved wording of the bullet points for portals, attribute whitelist changes, and server rendering changes - Add note about error boundaries including a breaking change to error handling behavior. - punctuation and capitalization fixes **why make this change?:** Clarity and correctness **test plan:** Visual inspection **issue:** facebook#8854

@gaearon

* First shot at updating changelog for 16.0 **what is the change?:** Added an 'unreleased' section to the changelog with info from #10294 **why make this change?:** To get things set for the 16.0 release. **test plan:** Visual inspection **issue:** #8854 * Fix typos and formatting errors in changelog * Add requestAnimationFrame and remove "New helpful warnings" **what is the change?:** In response to helpful code review - - Add mention of dependency on `requestAnimationFrame` and need to polyfill that as well as `Map` and `Set` - Remove "New helpful warnings" section; it was incomplete, and there are so many new and updated warnings that it might not be reasonable to cover them in the changelog. **why make this change?:** Accuracy **test plan:** Visual inspection **issue:** issue #8854 * Improve wording * Improve wording and fix missing links * Add backticks to file names & code; wording tweak * Break "Major Changes" into "New Feature" and "Breaking Changes" * Add server side render changes to 16.0 changelog * Change gist link from mine to gaearons * Add note about returning fragments * fix misc nits * Misc. formatting/wording fixes to changelog **what is the change?:** Thanks to the kind code review comments of @gaearon and @nhunzaker we have - removed the non-deterministic bold styling on some bullet points - improved wording of the bullet points for portals, attribute whitelist changes, and server rendering changes - Add note about error boundaries including a breaking change to error handling behavior. - punctuation and capitalization fixes **why make this change?:** Clarity and correctness **test plan:** Visual inspection **issue:** #8854 * fix broken link

@gaearon

* Update changelog for unreleased 16.0 changes (#10730) * First shot at updating changelog for 16.0 **what is the change?:** Added an 'unreleased' section to the changelog with info from #10294 **why make this change?:** To get things set for the 16.0 release. **test plan:** Visual inspection **issue:** #8854 * Fix typos and formatting errors in changelog * Add requestAnimationFrame and remove "New helpful warnings" **what is the change?:** In response to helpful code review - - Add mention of dependency on `requestAnimationFrame` and need to polyfill that as well as `Map` and `Set` - Remove "New helpful warnings" section; it was incomplete, and there are so many new and updated warnings that it might not be reasonable to cover them in the changelog. **why make this change?:** Accuracy **test plan:** Visual inspection **issue:** issue #8854 * Improve wording * Improve wording and fix missing links * Add backticks to file names & code; wording tweak * Break "Major Changes" into "New Feature" and "Breaking Changes" * Add server side render changes to 16.0 changelog * Change gist link from mine to gaearons * Add note about returning fragments * fix misc nits * Misc. formatting/wording fixes to changelog **what is the change?:** Thanks to the kind code review comments of @gaearon and @nhunzaker we have - removed the non-deterministic bold styling on some bullet points - improved wording of the bullet points for portals, attribute whitelist changes, and server rendering changes - Add note about error boundaries including a breaking change to error handling behavior. - punctuation and capitalization fixes **why make this change?:** Clarity and correctness **test plan:** Visual inspection **issue:** #8854 * fix broken link * Fixes #9667: Updated createTextInstance to create the text node on correct document (#10723) * Record sizes * Add a changelog for elements having the same key (#10811) * Add a changelog for elements having the same key * Reword * Markdown fixs on "DOM Attributes in React 16" post (#10816) * Include tag name into the table snapshot (#10818) * Update DOM warning wording and link (#10819) * Update DOM warning wording and link * Consistently use "Invalid" for known misspellings * Update license headers BSD+Patents -> MIT Did find and replace in TextMate. ``` find: (?:( \*)( ))?Copyright (?:$c$ )?(\d{4})\b.+Facebook[\s\S]+(?:this source tree|the same directory)\.$ replace: $1$2Copyright (c) $3-present, Facebook, Inc.\n$1\n$1$2This source code is licensed under the MIT license found in the\n$1$2LICENSE file in the root directory of this source tree. ``` * Change license and remove references to PATENTS Only remaining references: ``` docs/_posts/2014-10-28-react-v0.12.md 51:You can read the full text of the [LICENSE](https://github.com/facebook/react/blob/master/LICENSE) and [`PATENTS`](https://github.com/facebook/react/blob/master/PATENTS) files on GitHub. docs/_posts/2015-04-17-react-native-v0.4.md 20:* **Patent Grant**: Many of you had concerns and questions around the PATENTS file. We pushed [a new version of the grant](https://code.facebook.com/posts/1639473982937255/updating-our-open-source-patent-grant/). src/__mocks__/vendor/third_party/WebComponents.js 8: * subject to an additional IP rights grant found at http://polymer.github.io/PATENTS.txt ``` * Version bumps to use MIT license * Add ReactTestRenderer documentations (#10692) * Add ReactTestRenderer documentations * Add TestRenderer documentations * TestRenderer is not experiment * Add a link for jsdom * Use ES Modules syntax * Twaek * Add a Link component * Use Jest assertions * Move a documentation for createNodeMock to Idea section * Renamed * Tweak * Rename * More explicit * Add a usecase for createNodeMock * Add changelog for 15.6.2 * Add 15.6.2 blog post to master * Add Nate to authors on master * Bump object-assign patch range to match main package.json * Flow should ignore node_modules/create-react-class * Update error codes * Update CHANGELOG for React 16 * v16.0.0 * Doc updates for React 16 + blog post (#10824) * Doc updates for React 16 + blog post * Add link to Sophie's post * Fix React links on the website (#10837) * Fix React links on the website * Fix code editor * Fix code editor, attempt 2 * Doc change for prevContext removal in CDU (#10836) * Doc change for prevContext removal in CDU Ref: #8631 * Minor rewording * Fix note formatting * React.createPortal is not a function (#10843) * Update Portals Documentation (#10840) * Update Portals Documentation Correct some grammar to be more explicit and clear. Update example CodePen to better match code found in documentation. Update code example styles to match other code examples (ie. 'State and Lifecycle', 'Handling Events'). * Clean up comment to be accurate to example There was a small comment overlooked when reviewing the documentation. This fixes it to be accurate to the example as well as grammatically correct. * Update portals.md * More fixes * Update name of property initializer proposal (#10812) The proposal for property initializers is called [Public Class Fields](https://tc39.github.io/proposal-class-public-fields/) now (part of the combined [Class Fields](https://github.com/tc39/proposal-class-fields) proposal). * Fix portal link (#10845) * Update docs for React 16 (#10846) * Minor doc edit * Rename urls

gaearon · 2017-10-04T16:35:55Z

16 is out.
Remaining items moved to #11088.

**what is the change?:** This just updated the error codes on the docs. For my future self, recording the steps it took to get here: - On master, run `npm run build -- --extract-errors` - Create a commit with those changes, and open a PR (facebook/react#10619) - Cherry-pick that commit onto 15-stable, and open a PR (facebook/react#10621) - Update the error codes on the `gh-pages branch` by doing the following based on docs (https://github.com/facebook/react/tree/master/docs#updating-facebookgithubioreact): - Set up a sister directory to `react` with `gh-pages` checked out, and call it `react-gh-pages` - In your `react` repo, with `15-stable` checked out and the error-codes update cherry-picked, run: `cd docs && bundle rake exec && bundle exec rake fetch_remotes && bundle exec rake release` - `cd ../react-gh-pages` and check in those changes, create a commit/PR - Manually test running the docs **why make this change?:** Even though this is just an RC, and not a final major release, we still want the docs to be as up-to-date as possible. **test plan:** Run the docs locally and make sure things work. (Flarnie will insert screenshots.) **issue:** facebook/react#8854

leonardoelias mentioned this issue Jan 24, 2017

Edição 179 - 26/01/2017 braziljs/weekly#137

Closed

gaearon mentioned this issue Jul 26, 2017

Add fragment API to allow returning multiple components from render #2127

Closed

fregante mentioned this issue Jul 27, 2017

Show more than three Avatars for Reactions refined-github/refined-github#644

Merged

gaearon mentioned this issue Aug 3, 2017

Detect duplicated React facebook/react-devtools#714

Closed

mnpenner mentioned this issue Aug 4, 2017

Roadmap leebenson/reactql#10

Closed

13 tasks

bvaughn changed the title ~~React 15.5 and 16 Umbrella ☂️~~ React 16 Umbrella ☂️ (and 15.5) Aug 14, 2017

flarnie mentioned this issue Sep 6, 2017

Update error codes on docs branch #10622

Merged

flarnie mentioned this issue Sep 18, 2017

Update changelog for unreleased 16.0 changes #10730

Merged

gaearon closed this as completed Oct 4, 2017

React 16 Umbrella ☂️ (and 15.5) #8854

React 16 Umbrella ☂️ (and 15.5) #8854

Comments

gaearon commented Jan 24, 2017 • edited Loading

Past Releases

16 Final

16 Wishlist

Past Releases

15.5

15.6

16 Alpha

16 Beta

16 RC

aweary commented Jan 24, 2017

nhunzaker commented Jan 24, 2017 • edited Loading

jamiebuilds commented Jan 24, 2017

sophiebits commented Jan 24, 2017

gaearon commented Jan 24, 2017

jamiebuilds commented Jan 24, 2017

tizmagik commented Jan 24, 2017

klzns commented Jan 24, 2017 • edited Loading

jquense commented Jan 24, 2017 • edited Loading

quantizor commented Jan 24, 2017

gaearon commented Jan 24, 2017

Hurtak commented Jan 24, 2017

swernerx commented Jan 24, 2017

nakamorichi commented Jan 24, 2017

gaearon commented Jan 24, 2017 • edited Loading

gaearon commented Jan 24, 2017

dtinth commented Jan 24, 2017

gaearon commented Jan 24, 2017

swernerx commented Jan 24, 2017

swernerx commented Jan 24, 2017

MilosRasic commented Jan 24, 2017

gaearon commented Jan 24, 2017

nakamorichi commented Jan 24, 2017

gaearon commented Jan 24, 2017

zalmoxisus commented Jan 24, 2017 • edited Loading

gaearon commented Jan 24, 2017

nakamorichi commented Jan 24, 2017

gaearon commented Jan 24, 2017

nakamorichi commented Jan 24, 2017

iddan commented Jul 25, 2017

gaearon commented Jul 25, 2017

gaearon commented Oct 4, 2017

gaearon commented Jan 24, 2017 •

edited

Loading

nhunzaker commented Jan 24, 2017 •

edited

Loading

klzns commented Jan 24, 2017 •

edited

Loading

jquense commented Jan 24, 2017 •

edited

Loading

gaearon commented Jan 24, 2017 •

edited

Loading

zalmoxisus commented Jan 24, 2017 •

edited

Loading