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.