3 ms·
This is a bold, dangerous move. I can get on board with these lifecycle methods being abused, and instituting changes to the library to correct them. However, I
by cloverich 9y ago
This is a bold, dangerous move. I can get on board with these lifecycle methods being abused, and instituting changes to the library to correct them. However, I suspect there's an unimaginable amount of code that will need re-written to accommodate these changes. Is that a feasible expectation? Would it have been feasible to re-brand the library (or components) to support async rendering (with async components having that different API)? I don't know; I"m all in on React so I really hope this doesn't result in community split.
- acemarke 9y agoAs the post says, the migration will be handled gradually. All of the semi-deprecated `componentWill` lifecycles will continue to work as-is as long as you're on React 16.x. They'll start warning about using them in a later 16.x release. If you rename them to `UNSAFE_componentWill`, they'll continue to work the same way, and there will be a codemod released to do that transformation automatically. There will also be a `<StrictMode>` component built in to React that you can explicitly put around parts of your component tree to help locate these usages.
- brianvaughn 9y agoJust chiming in to note that the codemod has already been released: https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles https://github.com/reactjs/react-codemod#rename-unsafe-lifec... We used it internally (at Facebook) several weeks ago to update ~14,000 components that used the unsafe lifecycles.
- danabramov 9y agoMy answer here is relevant to this question: https://news.ycombinator.com/item?id=16696798 https://news.ycombinator.com/item?id=16696798