Skip to content

Commit

Permalink
Fixed links
Browse files Browse the repository at this point in the history
  • Loading branch information
bvaughn committed Mar 7, 2018
1 parent 6a1ba97 commit 1de2e33
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions content/blog/2018-03-20-react-v-16-3.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,15 @@ 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 it will enable.
For the past few months, the React team has been working on support for [asynchronous rendering](/blog/2018/03/01/sneak-peek-beyond-react-16.html). We are excited about the new features it will enable.

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, [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.
For many years, React has offered an experimental API for context. Although it was a powerful tool, its use was discouraged 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.

Expand All @@ -28,7 +28,7 @@ Here is an example illustrating how you might inject a "theme" using the new con

## `createRef` API

Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had [several downsides](https://github.com/facebook/react/issues/1373) and so our official recomendation was to [use the callback form instead](https://reactjs.org/docs/refs-and-the-dom.html#legacy-api-string-refs).
Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had [several downsides](https://github.com/facebook/react/issues/1373) and so our official recomendation was to use the callback form instead.

Version 16.3 adds a new option for managing refs that offers the convenience of a string ref without any of the downsides:
`embed:16-3-release-blog-post/create-ref-example.js`
Expand All @@ -39,11 +39,11 @@ Version 16.3 adds a new option for managing refs that offers the convenience of
>
> You don't need to replace callback refs in your components. They are slightly more flexible, so they will remain as an advanced feature.
[Learn more about the new `createRef` API here.](#)
[Learn more about the new `createRef` API here.](/docs/refs-and-the-dom.html)

## Component Lifecycle Changes

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.
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](/blog/2018/03/01/sneak-peek-beyond-react-16.html)) 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 [prototyping a React compiler](https://twitter.com/trueadm/status/944908776896978946).

Expand All @@ -59,7 +59,7 @@ We recognize that this change will impact many existing components. (At Facebook
We are also adding a new static lifecycle, `getDerivedStateFromProps`, as a safer alternative to the legacy `componentWillReceiveProps`.

[Learn more about these lifecycle changes here.](#)
[Learn more about these lifecycle changes here.](#TODO)

## `StrictMode` Component

Expand Down

0 comments on commit 1de2e33

Please sign in to comment.