4 ms·

Why call it "UNSAFE_" if there isn't really anything unsafe about it? I get it, they don't want people using those functions, but why should they decide what wo

by nukeop 9y ago

Why call it "UNSAFE_" if there isn't really anything unsafe about it? I get it, they don't want people using those functions, but why should they decide what work best for other developers and use shady tactics like dishonestly calling something they don't want to be used "unsafe" just so that it causes uneasiness and raises red flags with devs that aren't intimately familiar with React? Facebook is known for its underhanded tactics and React is no exception, they tried to kill patent disputes with its licensing in the past. Now they're trying to control how their library is used in a very deceitful way.

danabramov 9y ago
>Why call it "UNSAFE_" if there isn't really anything unsafe about it After seeing thousands of React components and responding to thousands of issue reports, we know which patterns often get people in trouble. Some of these patterns indicated bad design on our part, and we want to fix those issues. We are adding safer alternatives for these use cases that don’t have those pitfalls. Importantly, we want to clearly communicate that these existing methods cause problems and these problems will become more noticeable in future versions of React that will support asynchronous rendering. I gave a talk about what “asynchronous rendering” means for React, and about exciting new long-requested features it enables.[1] I encourage you to watch it if you’re curious about our motivations. These methods are incompatible with it, hence they’re “unsafe”. Since the risk of them being unsafe grows with time, we decided it’s worth adding a prefix to call them out in the product code. We’re trying to do best by our community and I’m sorry if we’re falling short of that. We set up an RFC repository[2] a few months ago so you’re welcome to give us feedback on the future changes. [1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-... [2]: https://github.com/reactjs/rfcs https://github.com/reactjs/rfcs
- nukeop 9y ago
  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.
Taig 9y ago
It's a common pattern in functional programming (e.g. in Haskell and Scala) to add an "unsafe" prefix or suffix to functions that perform dangerous side effects.

by nukeop 9y ago

danabramov 9y ago

>Why call it "UNSAFE_" if there isn't really anything unsafe about it After seeing thousands of React components and responding to thousands of issue reports, we know which patterns often get people in trouble. Some of these patterns indicated bad design on our part, and we want to fix those issues. We are adding safer alternatives for these use cases that don’t have those pitfalls. Importantly, we want to clearly communicate that these existing methods cause problems and these problems will become more noticeable in future versions of React that will support asynchronous rendering. I gave a talk about what “asynchronous rendering” means for React, and about exciting new long-requested features it enables.[1] I encourage you to watch it if you’re curious about our motivations. These methods are incompatible with it, hence they’re “unsafe”. Since the risk of them being unsafe grows with time, we decided it’s worth adding a prefix to call them out in the product code. We’re trying to do best by our community and I’m sorry if we’re falling short of that. We set up an RFC repository[2] a few months ago so you’re welcome to give us feedback on the future changes. [1]: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-16.html https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-... [2]: https://github.com/reactjs/rfcs https://github.com/reactjs/rfcs

nukeop 9y ago
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.

Taig 9y ago

It's a common pattern in functional programming (e.g. in Haskell and Scala) to add an "unsafe" prefix or suffix to functions that perform dangerous side effects.