Makzan / I share what I learnt

On handling breaking changes in React

React is very careful for their updates and how things should work. Then the React team introduces new features, they will introduce it in advance and if changes contain breaking API change, they will rename deprecated methods and only remove it after enough preparation time from the community.

Take the componentWillMount method as example. It was introduced in 2018 March and it is not removed until yet upcoming v17.

https://reactjs.org/blog/2018/03/27/update-on-async-rendering.html#gradual-migration-path

They even provide tools for easier migration. For example, the codemod script for the method mentioned above.

https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#renaming-unsafe-lifecycle-methods

The new names like UNSAFE_componentWillMount will keep working in both React 16.9 and in React 17.x. However, the new UNSAFE_ prefix will help components with problematic patterns stand out during the code review and debugging sessions.

https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#renaming-unsafe-lifecycle-methods

And the renamed UNSAVE_componentWillMount method will continue works even in upcoming v17.x. So a deprecated method takes years to be truly removed from the code base to give community time to adapt to the latest best practice pattern.

This is indeed following their own commitment to stability.

https://reactjs.org/docs/faq-versioning.html#commitment-to-stability

As we change React over time, we try to minimize the effort required to take advantage of new features. When possible, we’ll keep an older API working, even if that means putting it in a separate package.


Published on 2020-01-18. More articles like this: ReactJS, Web Technologies.

Want productive tips and web technologies links like this in your inbox each week? Sign up for weekly dispatch each week. No spam ever. Just useful content: