81–90 of 120 posts
No new feature, yet contains breaking changes.
So what? That's how semantic versioning works, it wouldn't be a major point release without the breaking changes.
Earlier quoted context omitted.
Do you actually think hooks are worth dropping? I see the appeal of classes, but I really enjoy hooks too.
I think they're better off as a separate library (similar to react-transition-group), as someone else has suggested in the comments. There's certain cases where they come in handy, I understand this, but they didn't need to be baked into React. I really dislike the way they can be abused to litter state and side effects all over React code so easily (e.g. hiding it layers deep in helper functions). And I feel they've…
It makes it much easier to have composable functions/state, which I love.
const [x, setX] = useState()
useEffect(() => {
let isMounted = true
someAsyncFunc(result => {
if (isMounted) {
setX(result) // should not be called on dismounted component
}
})
return () => { isMounted = false }
}, [])
return
Imo choosing a different name for new useEffect would be better (like useAsyncEffect or introducing a parameter), because just changing its behavior won't even result in compilation errors or guaranteed run-time errors, only make old code unstable.
Is there a way to reliably detect if component is still mounted before updating it when doing async operations in effects?
No new feature, yet contains breaking changes.
As stated in the post, the breaking changes are intentionally minimal. For example, we haven't removed any of the APIs that were originally slated to be removed in 17.
By all means make breaking changes, just maybe tone down the marketing.
It contains a very serious breaking change: cleanup in useEffect is now being executed asynchronously. I might not be seeing something, but I think this means all patterns like the one below will now have hard to catch racing conditions. const [x, setX] = useState() useEffect(() => { let isMounted = true someAsyncFunc(result => { if (isMounted) { setX(result) // should not be called on dismounted component } }) retur…
So code like this can stay written exactly as it does today. As noted in the blog post we’ve only had to modify ~20 components out of thousands so although this change may cause some breakage (please report anything unusual to the issue tracker!) we’re fairly confident that such common patterns continue to work.
(Edit: added this to the post.)
"It has been two and a half years since the previous major release of React, which is a long time even by our standards!" As a mostly Python and only occasional JavaScript developer, it always felt like the biggest challenge in the JavaScript community was how fast everything moved - new libraries, frameworks and ideas would tumble past at the rate of one every few weeks, and it felt impossible to keep up. I've been…
> the biggest challenge in the JavaScript community was how fast everything moved If you don't like things moving too fast, then React does seem to be the ideal ecosystem: https://github.com/facebook/create-react-app/issues/9033#iss... TL;DR A vulnerability was discovered in a transitive dependency of "create-react-app" and announced back in March, but the one line patch to update the hard-coded reference to the vuln…
While I agree that ideally a release should be cut to satisfy people affected by enterprise requirements, we are looking at a case of an overzealous audit checker, not an actual vulnerability that affects your apps.
(Edit: I've cut a release though; see my response in https://github.com/facebook/create-react-app/issues/9033#iss...)
Earlier quoted context omitted.
I think they're better off as a separate library (similar to react-transition-group), as someone else has suggested in the comments. There's certain cases where they come in handy, I understand this, but they didn't need to be baked into React. I really dislike the way they can be abused to litter state and side effects all over React code so easily (e.g. hiding it layers deep in helper functions). And I feel they've…
This is fair, but I really enjoy using hooks. I personally feel my code is faster to write and easier to understand. It makes it much easier to have composable functions/state, which I love.
They certainly work when you memorise the rules and syntax, but it feels very contrived even when it all makes sense.
Earlier quoted context omitted.
As stated in the post, the breaking changes are intentionally minimal. For example, we haven't removed any of the APIs that were originally slated to be removed in 17.
I think the marketing line of "No new features" could lure people into a false sense of security on this upgrade, even if the breaking changes are minimal. By all means make breaking changes, just maybe tone down the marketing.
In my opinion this goes WAY beyond the usual changelog entry in other repositories.
It's refreshing to see a major release of a frontend library that doesn't completely redo the API (React Router and Angular, take note). I remember there was a time when a bunch of features were being considered to be bolted on to JSX which was going to be called JSX 2.0[0]. I'm glad that never happened. Maybe the next version of React can even remove features, like hooks. 0. https://github.com/facebook/jsx/issues/65
I'd still _loooove_ to have "prop punning", ie, shorthand passing of props based on local variable names equivalent to ES6 object literal shorthand: Doesn't seem too likely to happen at this point, though.
Earlier quoted context omitted.
Big name libraries and frameworks like React and Angular manage things relatively well and in a similar way to other frameworks in other languages (you could argue about AngularJS -> Angular but if you worked with both frameworks you know that AngularJS was a dead end approach designed for a completely different stack and it just didn't make sense to maintain backwards compatibility or maintaining that dumpster of a…
Which core web app framework feature’s biggest 3rd party React library has been abandoned in the last few years? Or extensively rewritten to the point of seriously effecting end using programmers? I am relatively new to React. Perhaps all of this happened 3 or more years ago. I know React Router 4 was released in mid 2017. Perhaps I was too new when I looked over the changes between 3 and 4. It didn’t seem as drastic…