11 ms·

Why not just deprecate this API in addition to providing a better way to perform operations commonly invoked this way?

• danabramov 9y ago
  That’s the plan (and it’s what the blog post says). However both Facebook and large products at other companies have too much code that depends on those lifecycles. Potentially thousands of components. So it’s infeasible to completely deprecate them. At least not within a time frame of a year. This is why we’re still leaving the “unsafe” aliases in React 17 so that people can opt out of async rendering and keep using those while they’re not ready to migrate. Since we need some version of the hooks to stay, we need to clearly differentiate them so that new code doesn’t use them. Hence the prefix.
• brianvaughn 9y ago
  We are trying to strike a balance between supporting huge legacy apps that cannot be rewritten- (something Facebook has a lot of)- and encouraging safe/bug-free coding practices for future apps. In this case, we felt the right balance was to preserve legacy functionality while using a name that would hopefully discourage new usage (so as to avoid the potential pitfalls inherent in the legacy API). And we provided a codemod to help with the "huge legacy apps": https://github.com/reactjs/react-codemod#rename-unsafe-lifecycles https://github.com/reactjs/react-codemod#rename-unsafe-lifec... We've run it internally already to update ~14,000 components.