lukechilds
/
react.dev
mirror of https://github.com/lukechilds/react.dev.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
Browse Source

Incorporated Sophie's PR feedback

main
Brian Vaughn 7 years ago
parent
08d444eada
commit
5a1d653f76
1 changed files with 11 additions and 9 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Split View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 20
      content/blog/2018-02-07-react-v-16-3.md

20
content/blog/2018-02-07-react-v-16-3.md
View File

@ -5,19 +5,21 @@ author: [bvaughn]
This release includes a new class component lifecycle (`getDerivedStateFromProps`), a new `StrictMode` component, an official context API, and a new ergonomic ref API!
For the past few months, the React team has been working on support for [asynchronous rendering](#). We are excited about the new features this will enable, and we've learned that some changes will be required to the way we write React components.
For the past few months, the React team has been working on support for [asynchronous rendering](#). We are excited about the new features it will enable.
We're releasing version 16.3 primarily so that open source maintainers can start incorporating these changes into their libraries well in advance of the next major release. **However, you should not feel pressured to make changes to your application code yet.** We respect semver and will not ship breaking changes in a minor version!
We've also learned that some long-term changes will be required to the way we write React components. However, we respect semver and **will not ship breaking changes in a minor version**!
Read on to learn more about the release.
## Official Context API
For many years, React has offered an experimental API for context. Although it was a powerful tool, our advice was mostly to [avoid using it](/docs/context.html#why-not-to-use-context) because of potential problems with the API. We've always intended to replace the experimental API with a better one, and as of version 16.3 the new API is available!
For many years, React has offered an experimental API for context. Although it was a powerful tool, [its use was discouraged](/docs/context.html#why-not-to-use-context) because of inherent problems in the API, and because we always intended to replace the experimental API with a better one.
Version 16.3 introduces a new context API that is more efficient and supports both static type checking and deep updates.
> **Note**
>
> The old context API will keep working for all React 16 minor releases, so you will have time to migrate.
> The old context API will keep working for all React 16.x releases, so you will have time to migrate.
[Learn more about the new context API here.](#)
@ -40,7 +42,7 @@ Version 16.3 adds a new option for managing refs that offers the convenience of
React's class component API has been around for years with little change. However, as we add support for more advanced features (such as [error boundaries](/docs/react-component.html#componentdidcatch) and the upcoming [async rendering mode](#)) we stretch this model in ways that it was not originally intended.
For example, with the current API, it is too easy to block the initial render with non-essential logic. In part this is because there are too many ways to accomplish a given task, and it can be unclear which is best. We've observed that the interrupting behavior of error handling is often not taken into consideration and can result in memory leaks—(something that will also impact the upcoming async rendering mode). The current class component API also complicates other efforts, like our work on a React compiler.
For example, with the current API, it is too easy to block the initial render with non-essential logic. In part this is because there are too many ways to accomplish a given task, and it can be unclear which is best. We've observed that the interrupting behavior of error handling is often not taken into consideration and can result in memory leaks (something that will also impact the upcoming async rendering mode). The current class component API also complicates other efforts, like our work on [prototyping a React compiler](https://twitter.com/trueadm/status/944908776896978946).
Many of these issues are exacerbated by a subset of the component lifecycles (`componentWillMount`, `componentWillReceiveProps`, and `componentWillUpdate`). These also happen to be the lifecycles that cause the most confusion within the React community. For these reasons, we are going to deprecate those methods in favor of better alternatives.
@ -50,7 +52,7 @@ We recognize that this change will impact many existing components. (At Facebook
>
> Deprecation warnings will be enabled in version 16.4, **but the legacy lifecycles will continue to work until version 17**.
>
> After version 17, it will still be possible to use them, but they will be aliased with an "UNSAFE_" prefix to indicate that they might cause issues. We have also prepared an [automated script to rename them](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) in existing code.
> Even in version 17, it will still be possible to use them, but they will be aliased with an "UNSAFE_" prefix to indicate that they might cause issues. We have also prepared an [automated script to rename them](https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles) in existing code.
We are also adding a new static lifecycle, `getDerivedStateFromProps`, as a safer alternative to the legacy `componentWillReceiveProps`.
@ -58,11 +60,11 @@ We are also adding a new static lifecycle, `getDerivedStateFromProps`, as a safe
## `StrictMode` Component
`StrictMode` is a tool for highlighting potential problems in an application. Like `Fragment`, `StrictMode` does not render any visible UI. It simply activates additional checks and warnings for its descendants.
`StrictMode` is a tool for highlighting potential problems in an application. Like `Fragment`, `StrictMode` does not render any visible UI. It activates additional checks and warnings for its descendants.
> **Note:**
>
> `StrictMode` checks are run in development mode only; they do not impact the production build.
> `StrictMode` checks are run in development mode only; _they do not impact the production build_.
Although it is not possible for strict mode to catch all problems (e.g. certain types of mutation), it can help with many. If you see warnings in strict mode, those things will likely cause bugs for async rendering.
@ -73,4 +75,4 @@ In version 16.3, `StrictMode` helps with:
Additional functionality will be added with future releases of React.
[Learn more about the `StrictMode` component here.](#)
[Learn more about the `StrictMode` component here.](/docs/strict-mode.html)

Write Preview
Loading…
Cancel
Save