"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 feeling that a lot less recently, and maybe the fact that React has been steady for 2.5 years is part of the reason.
> 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
Those of us who were doing Python web dev in the years 2000s might remember that Python went through a similar period where it seemed that every week a new backend framework came out: Zope, CherryPy, web2py, Pylons, Django, repoze.bfg, TurboGears... to name a few. Nowadays it seems that everybody has settled for either Django or Flask. It might not have been as crazy as what happened with JavaScript in the years 2010s but still I tend to see a similar pattern. People try a lot of different things, going in slightly different directions and eventually interesting approaches get identified and communities build up around a couple of solutions.
Meanwhile the Ruby community was able to build consensus around Ruby on Rails, with just Sinatra on the side for small projects.
I'm wondering if this ability to try many different things might have been the cause for Python building numpy and eventually winning the scientific computing area as well.
I do think there's a second wave of frameworks coming, because Django/Flask are showing their age a bit. Sanic is/was really popular and I think FastAPI is really promising.
Sanic is indeed just an ASGI version of Flask, though who knows how it will develop in the future - but FastAPI is a whole other beast. Also, Django is adding support for ASGI so no, that's not the main difference I wanted to point out.
I second you on that. The number of times I've had to rewrite code because a framework decided to break everything with little warning.. I don't even want to think about it actually. I get wanting to make code better but gesh people, do some planning and figure out a direction to move a project.
Also it seems JS devs don't understand semver either. Massive breaking changes in patch or minor versions are just evil.
React is actually pretty decent in terms of upgrading. Also, the idea of semver is more widespread in the JS community and there are things like Angular commits and tools like commitizen.
It has a tick-tock pattern so that you can upgrade and having time to fix the warnings.
The API changes are carefully crafted.
Sometimes there are even migration tools to help you upgrade.
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 code base past it's EOL).
A problem in React ecosystem is that it's a rendering library not really a webapp framework so you need to use community provided libraries to fill in the gaps. Those libraries are often maintained by an individual so it's unreasonable to expect corporate SDK approach to development, but unfortunately it leads to a lot of abandonware and rewrites, especially since JS is not very maintainable and it's often easier to rewrite something than to pick up someone else's code.
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 as the general opinion that JS changes like crazy. I looked at the migration guide again. Still doesn’t look too bad. Maybe it would be in a large code base.
I am developing with React and TypeScript every day for the past 5 years. Everything I did then works now, not a single line of code needed to be changed. There are new ways of doing things that I am extremely happy with (Hooks, advanced types), but the old way is not even deprecated yet.
I'm surprised that you don't see the changes between RR3 and 4 as drastic. It's a completely different API, and unsolved a problem which had (admittedly imperfect) solutions -- kicking off data fetching prior to navigation.
I try to resist hyperbole, but if it wasn't for the brand value of owning the name "React Router", it should (or would) have been released under a different package name.
react-router, react-router-redux, immutable.js was dead at some point when the only dev maintaining it left Facebook (AFAIK, I don't know if it got resurrected since) and people were just moving to immer.js. These are just on top of my head stuff that I had to replace when starting new projects because I didn't want to start a new project on potentially unsuported libs, there were more but I can't remember the names exactly - been a while since I was boostraping a new project.
I've had similar experiences with JS libraries, but not so much with React. The React team are much better at managing to keep things backwardly compatible than most.
Agreed, I'm fairly new to React this year and while it's been a rough learning curve for me it's nice how stable it is considering some of the example code is pretty old and it still mostly works just fine
React has actually been stable for much longer than that (say 5 years). There have technically been breaking changes, but in practice these required only minor code changes if any. They've introduced new coding styles (like hooks), but the olds ones still function just fine.
So glad Angular is dying off. It looks nice on the surface but as soon as you try to do something outside the tutorial it gets nutty.
React is at a great level of abstraction between code and UI framework. It reminds me of the MVC frameworks of olde, which by all accounts were great, just limited because they relied on page refresh for everything
I come from Angular (Angular.js, Angular 2, 4, 5, 6 and 7) and now work on React.
React works really well but if I chose it for a personal project today it would only be to avoid switching back and forth, not because I think it is better.
Uh, I'm gonna challenge you to give a source on that. Your comment sounds extremely biased towards React and dismissive towards Angular. None of those are dying out, I wouldn't we even say they compete directly.
I've worked on Angular stuff for years because my employer won't let us switch. Angular uses too much abstraction.
Angular does crazy things to the templates, to the point that trying to build your own UI widgets is a recipe for pain.
Template meta-language is stupid. It's just similar enough to JS that you mess up the syntax all the time and never really stop. Since it's not just JS like JSX there's not good linting support either.
Related, stupid "pet features" and hydra syndrome. Like Pipes. Why does Angular use these weird pointless things when you can do the same thing with JS built-ins? Just so they didn't have to copy JSX? We may never know. And why are there 2 form implementations that both feel half baked? Why is it so bad to instantiate components for testing? Why does it mangle the code to support dependency injection when decorators and DI support don't even actually exist in JS even in ES2018? Why is Polyfills.js such a minefield? I could go on but really, why are so many things half assed and haphazard. It reminds me of Go...
Constant "expression changed after it was checked" errors because the data model change tracking is fundamentally broken
Repeated refactoring of HTML form interop and it still kinda sucks
Major breaking changes on nearly every upgrade that take days to do, even on our small apps.
Crappy documention. There's no usage examples for most of the library, just the Angular version of Javadoc.
Terrible bike shedding by Angular and Material teams. I'm following a bunch of issues and I've never seen one closed. I've been following some of the threads for years.
That was a nasty rant but I have plenty of things to hate about Angular. React on the other hand has a mostly clean core API and doesn't force all this baggage on you. IMO this has spawned a competitive ecosystem where the bad ideas get shaken out. Angular is stuck in the past and feels creaky compared to React development these days.
JSX is the future. It's exactly how MVC frameworks used to work, and it would be popular for templating even if the rest of React didn't exist. Change tracking with props is another. It's simple, it works. Angular change tracking errors are the segfaults of front end dev
>Constant "expression changed after it was checked" errors because the data model change tracking is fundamentally broken
Sounds like are doing something wrong. At least I can't remember that particular one from three years of Angular >=2
> Repeated refactoring of HTML form interop and it still kinda sucks
Major breaking changes on nearly every upgrade that take days to do, even on our small apps.
I did most of upgrades for over a year I think. They were mostly trivial after reading up on the changes and I don't consider myself a 10x engineer. Pro tip: Learn to use this repo: https://github.com/cexbrayat/angular-cli-diff
> Crappy documention. There's no usage examples for most of the library, just the Angular version of Javadoc.
Not perfect (internal inconsistentencies where one paragraph says "don't do this" and a couple of pages down they do exactly that).
But far far from Javafoc.
> Terrible bike shedding by Angular and Material teams. I'm following a bunch of issues and I've never seen one closed. I've been following some of the threads for years.
I don't like Material either ;-)
For everyone else:
Like always: keep it simple. Stick with the standards. Use a good ide/editor. Use Angular CLI, stick to the style suggested by that even though you don't have to use it for every small thing.
Angular is 100% fading, albeit slowly. Seems like a lot of slow moving enterprise companies are still going with it anecdotally. I'd bet on very few new projects opting for it currently, and probably near zero within 2-3 years.
As to why, IMO Vue ate Angular's lunch. Single file components did everything angular's MVC wanted without all the failures like $scope and other things. React and Vue can coexist, but I think Vue and Angular are direct competition. Also see those developer surveys and the massive growth of popularity of Vue along with angular's fading.
The 2019 popularity link isn't, and the technicality difference between AngularJS vs 2+ isn't incredibly relevant at this macro level when AngularJS's failures are very much a reason 2+ failed to be adopted. While it came with big changes, it's still not that significantly night and day different to act as if they aren't related.
You're right that MVC no longer applies, but Vue's components still beat Angular 2+ and the dev world seems to have spoken pretty loudly about feature preference/priority, and many of those mean Vue over Angular while leaving React a bit more in its own world.
I agree in the broad sense, but this isn't entirely true.
Feature-wise, Next does seem like a superset of Gatsby, especially since it can support server, static and hybrid rendering models. Architecturally, Gatsby does have some advantages. They're not ones that are particularly important to me, but I don't think it's fair to ignore them:
- The plugin model is more sophisticated, and there's a huge ecosystem of them which can solve most common use cases.
- The ability to use a unified data graph means page invalidation and rebuilds upon data changes can be done automatically at a very granular level -- because it's possible to keep track of which pages would be affected by every piece of data.
I'd add that I have issues with both, which leads me more to Next.js because it has a lower level of vendor lock-in compared to Gatsby. Anecdotally, migrating a small site from Gatsby to Next.js replaced 150 Gatsby-related imports with 10 Next.js ones.
(not GP) with React, declarative JavaScript code can result in HTML. JS -> HTML
Server side frameworks (the usual favourites) have existing ways for code to result in HTML. Ruby/PHP/Java -> HTML
Vue on the other hand can sit within HTML. So you can sprinkle in client-side logic in the views while still generally going with the grain of your server side framework.
We definitely seem to be in an era of stability. My stack of choice (React, GraphQL, Relay, Django) has remained unchanged since late 2015. A few things have changed, i.e. I no longer have to hand-roll my own SSR solution, because things like Next.js exist. But what represents the bulk of my code is largely the same tech as it was 5 years ago.
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 vulnerable version is being held back for a future major version upgrade of the "create-react-app" package. 5 months on and the issue is marked as Closed but the new version hasn't been released.
To be clear, the vulnerability has no actual effect on CRA apps. The description says it’s for a DDOS attack which is completely irrelevant because CRA doesn’t use WDS for production environments. (It doesn’t even have a production web server.)
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.
Thank you for your professionalism and humility. I too would like to apologise for not giving the full context and incorrectly suggesting that the vulnerability might actually affect apps created by CRA.
I think that the real concern was not the non-existent security implications (although it's a bad habit to ignore even an overzealous audit checker), but that the release process for CRA seemed to make it very hard to cut new patch releases. Your comment suggests that it wasn't so hard after all, for which I am relieved and grateful, but the policy of expecting people to wait for (and deal with the backwards incompatibility of) major version updates[0] doesn't feel like an industry best practice.
I think there are definitely things that could be improved in the release process there. The project is mostly run by volunteer contributors as there are limited things we can focus on, and currently we're very focused on React itself. If someone were to volunteer to streamline the release process and improve it, I'm sure the maintainers would have been appreciative.
I'm excited to see the work on the Modern Event System land. I tried to dig into all the events code in React to understand how events in React Portals bubbled up because I wanted to prevent them from bubbling out of the portal in many cases (GH issue: https://github.com/facebook/react/issues/11387). In 16.x, the modern event system was in the tree but unused by default, and it was very confusing to try to trace event handling logic between the two event systems. Removing the legacy event system will make the event system much more accessible to new contributors.
Can someone on the React team speak to how event delegation works when there are portals present? Where is the event handler for a portal bound, and how does the new events system handle event bubbling across multiple versions of React in portal trees?
Yeah, we've removed a lot of code and also a lot of abstraction so the event system should be easier to follow now. We listen to events on both roots and portal containers — this is why it keeps working.
I can't speak to the exact semantics of how portals work with nested trees, but if you find an issue, please file one on our tracker. Some are expected to be impossible to solve, but hopefully we handle the common cases well.
(I would ask Dominic who worked on this but he just went on a much needed holiday break.)
I've become increasingly disillusioned with the JS ecosystem over the past couple of years, but React still delivers. I can still chuck it in a script tag and start writing components if needed (without JSX). I haven't really used hooks yet and don't plan to, but as long as "legacy" class based components are supported, I will use them.
Thanks for maintaining backward compatibility, which is not very common in the JS world. And congrats on the release!
Just chiming in to say that I too hope class components will continue to be supported. I worry that they'll announce otherwise in a couple years.
Class components are so stupidly simple to read and write. I appreciate the work put into function components, but to me they make things unnecessarily complex. Just the fact that they took callbacks and other functions from methods – where things are separate, clean, standard – to nested functions – where things are not separate (some local variables, some closure variables), not clean (no possible way to unit test a nested function in isolation), and not standard (object methods are a language feature, use them!) – seems like a huge step backward.
You can create isolated functions instead of nested functions wherever you want. Just pass in params instead of using closures. This is entirely up to the developer.
Yep. And isolated functions are a solution, but sometimes it just makes way more sense for that function to be a method of a class. And for the function component to be a class component. I think there's space for both types of components, and I just hope that class components don't become deprecated.
I'm not aware of any case in which this is true. Effects are run on every render unless you explicitly specify dependencies in the second argument of the hook.
I wish this approach to be followed by all major repos and maintainers and become a new trend across all the tech industry.
By creating `bridge` release, the React community created a safe, well know and stable release that works as bridge for the upcoming complex, feature rich, release.
So: Complex Release -> Stable `bridge` Release -> New Complex Release.
Anyone can stay as long as they want in the bridge release, others can quickly move forward to the next release cycle.
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
}
})
return () => { isMounted = false }
}, [])
return <MyComponent x={x} />
In this example it's possible that component will be unmounted, then completion handler will run and try to modify state before cleanup function will be able to set the flag.
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?
Thanks for raising this concern. This particular example is not a problem in practice because React will not fire the warning about setting state in the short period between unmounting and cleanup. (We have special code and tests specifically for this case.)
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.
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.
There's a lot of "gets you most of the way there" hacks with JSX that will fill most needs. Where as you can imagine the incredible cacophony of screaming developers who maintain TypeScript, Preact, IDEs, etc. that would be incensed by breaking changes to JSX introduced just to solve some inconveniences.
Trust me, I'm well aware of both of those facts :)
Doesn't mean the syntax _can't_ change . After all, the `<>` shorthand syntax for fragments was added via cooperation with the Babel and TypeScript teams, and the work on the new `jsx()` replacement for `createElement()` is going the same way.
Which is why the current JSX syntax uses that as a synonym for `disabled={true}`. Agreed that it matches HTML better, but having written an awful lot of `someLongVariableName={someLongVariableName}`, I sure wish I could stop repeating myself there.
I, too, find it ridiculous to repeat `foo={foo}` over and over again. So I use the spread operator with ES6 shorthand object syntax. Now it’s `{...{ foo }}`. No breaking changes needed!
I thought this style was generally disfavored? It's perfectly possible to pass `true` as a valueless prop (<MyComponent disabled />); and yet either the default typescript linter, or typescript itself (I never investigated) complains of this syntax.
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 made the API worse, such as `this` being replaced with the more clumsy `useRef`, or requiring an empty array to change the behavior of `useEffect`. These are things that break the Principal of Least Astonishment and have consequently led to countless blog posts that try to explain how to do things that were much more straight forward without hooks.
It's certainly faster to write once you get the hang of it but I don't think it's easier to understand. People seem to converge on multiple useEffect's with anonymous functions with non obvious scope for variables, empty arrays to designate behaviour that isn't obvious, lots of subtle async gotchas, stale state variables, etc.
They certainly work when you memorise the rules and syntax, but it feels very contrived even when it all makes sense.
> empty arrays to designate behaviour that isn't obvious
This drives me a little crazy too. That behaviour can be easily documented by wrapping it in a function with a name that makes sense, but people litter their React code with non-obvious hooks everywhere. You can reduce a lot of boilerplate (why are you writing empty arrays everywhere!?) and improve readability substantially by wrapping the hooks in more composed and idiomatic functions.
I think that was along the lines of what was intended for hooks, but I don't see it often.
Was just thinking that we're probably due for a major release sometime now that Concurrent Mode seems to be starting to mature a little (disclaimer: it's still experimental, don't use it in production yet, etc.)
I'm sure the React team must be eager to get all the juicy changes out of the experimental branch and into the hands of developers. So it's great to see though that they're still taking their time to do it properly. Looking forward to seeing what come nexts :)
Hm. I like the idea of gradual upgrades in theory, but I worry the reality will be sites loading at least two versions of React semi-permanently. And possibly even worse, you end up with an NPM dependency nightmare of off-the-shelf component X using an entirely separate React runtime.
Yet more excess JS downloading and running on client devices, all in the name of superior developer experience. I hope my cynicism is proven wrong!
Totally hear your concern! To be clear though, it's not like we're forcing anyone to follow this approach. It was just broken before, in the same way that putting React inside a Vue/Svelte/jQuery app was subtly broken. So we've fixed the root cause but I totally agree it's only a solution to be used as a last resort. (E.g. like in our case, where many "long tail feature" components were written in 2013 and no teams own them.) In either case, even if you follow this approach, we strongly recommend to only load the second version lazily on screens that need it — like the demo shows.
It's very suboptimal but I think it's still better to have that option than not to have it — or to try it and run into insurmountable problems. Especially in big long-running projects like internal company dashboards where long-term maintenance is more important than time to first render.
(I don't know why you're being downvoted though! I think your concern makes a lot of sense, and we're also sensitive about how to balance the messaging so that people don't use this unnecessarily.)
It's sometimes easier and saner to develop a new component on something like stactblitz or a new angular project than make a change, wait 20s+ for compiler+browser to compiler and load code and view the new change. And repeat. And losing the hot-reloading with state b/c of the OOP heavy architecture in some shops, well that's not helping speed up write/reload/view change cycle at all.
And as you write larger and larger apps, with hundreds of components, it's just ridiculous how poorly the first-party tools handle that kind of code scale. Your only choice it to buy into Bazel to maintain some sense of sanity and productivity albeit some of which gets diminished with the overhead of learning, using and maintaining bazel for the project.
Complexity on top of complexity, nothing about Angular is simple.
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.
This is actually amazing, by making the next release with only breaking changes, and without new features, devs can focus strictly on what needs to be fixed.
Allowing code to be properly ready and tuned for the next major release. Where the new features will be actually introduced, hopefully, without new bugs.
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.
Don't get me wrong, this is great documentation, very high quality, and well done to the React team for a great release and what I think is a solid decision around what to include and what not to include in this release.
I think it's important to understand though that React is _marketed_, and unfortunately for many a name as clearly stated as this will likely define their expectations significantly. This could be especially pronounced for those who are less proficient in English.
I was pointing it out because people might misunderstand "no new features" as there being no change that they need to be aware of (e.g. internal restructuring).
to be fair one changes bites me aswell, but I always new everything is "async" in react functional components and I've often needed to write stuff to get around that. but effect cleanups are different and I just did not care.
"Zero new features" was a nice marketing line for Snow Leopard. It did not reflect reality. Snow Leopard introduced Dock Exposé, Exchange support in Apple Mail, and Grand Central Dispatch. just to name three.
We've had similar releases since then which added a few new features but were primarily focused on stability. The most recent one was High Sierra. These do tend to be the best releases of macOS IMO.
Well, we're also downplaying it a little bit, as component stack traces in production or fixing event delegation semantic across roots are significant new compelling use cases. :-)
But yeah, I'm mostly just referring to quality-of-life improvements as being a focal point of the release.
IMO Hooks is the best thing that happened to React. Once you get used to it it is a lot more clean and productive. It requires you to unlearn a few things though, e.g. don't think about component lifecycles, but think about data flow/changes. Once you get used to it is a lot more productive and enjoyable way of developing React apps.
I believe it would have been better to have Hooks as a separate library, not part of React. For the developer it is just another design pattern, not really an improvement, especially if you look at all the edge cases and issues you'll find around.
Personally I don't like the design pattern, a matter of taste. But it's very annoying now in the market to have mixed React and Hooks codebases, with all their issues..
How about you don't make it personal, and limit whatever criticism you have to technology. And why not include actual criticism, rather than just stating that you personally are not a fan. Thanks for the pointless comment otherwise.
I'm pretty sure hooks weren't his idea. Can't remember where he said that. The fact that he enjoys communicating doesn't mean he is the only one working on react.
I think React hooks are silly but Redux is an OK solution to a certain problem, and one of the nicer major libraries in all of JavaScript land, wildly better than almost anything else of similar prominence (it's fairly small and IIRC it has one dependency, with one other transitive dependency, and that's it). I don't see the philosophical or practical connection between the two.
`redux@^4` currently has two dependencies: `symbol-observable` for compat with observable libs, and `loose-envify` for compat with Browserify. I plan on removing both of those when we release Redux v5.
Our official Redux Toolkit package [0], which is now our recommended approach for writing Redux logic, _does_ have a few more deps: Immer, Reselect, Redux-Thunk, and the Redux core. But, those are all things you probably would have had in your app anyway.
If you're not familiar with Redux Toolkit, it includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once.
I just published a brand-new "Redux Essentials" core docs tutorial [1], which teaches beginners "how to use Redux, the right way", using our latest recommended tools and practices. I'd encourage folks to check it out.
Thanks for your work on it. I've found Redux super-helpful and pleasant to use for multi-platform JS UI work, in particular, to bundle HTTP client (and other network services, if not in the browser) libs behind a common, small, well-understood-by-React-devs state interface. I'm a huge fan of dependencies I can abuse—fake-up in an afternoon on unsupported platforms in another language, rip out of one place and cram in another without a fuss, stuff like that. Redux is one of the rare deps in JavaScript I never feel queazy about including in a build.
I'm too out-of-the-loop these days to know what Immer is, will have to give it a look.
Immer is an incredibly useful immutable update library, created by Michel Weststrate (author of MobX).
It exports a single function `produce(originalState, updateCallback)`. The callback receives a `draftState` value that _looks_ like your original state, but has been wrapped in an ES6 Proxy. You can then "mutate" the draft all you want. Internally, Immer tracks all the mutations, and the final result is a safely immutably-updated value.
It drastically simplifies immutable update logic - no more nested spread operators!
When I first came across Immer, I wasn’t impressed. I though “If you’re going to the trouble of using functional-ish state management, why add a “mutations-like” API in there. Surely you’re “crossing the streams?”
But then a couple of weeks later I had to wrangle data in subsections of three “slices“ of state at the same time.
Immer lets you focus on just the state you want to change, and hides the problem of maintaining the state you don’t want to change. Brilliant. I’ll take the “it looks like mutation” hit for that.
Yeah, Dan's pointed out a number of times that even with FP and immutability, _local_ mutation is fine. After all, the mechanism for immutable updates is to make copies of the original data, and then mutate / overwrite pieces of the copies.
Immer just does that in a really slick way.
My only concern for using Immer by default in RTK is the potential that someone would learn Redux by osmosis through looking at a codebase where every reducer is doing `state.someField = someValue`, think that actual mutation _is_ the right way to use Redux, and then try to do the same thing in another project and actually mutate data for real.
I can't prevent that, so my only answer was to repeatedly emphasize in this new tutorial that you _must_ do immutable updates, and that you can _only_ "mutate" inside of RTK's APIs thanks to Immer:
`symbol-observable` is just a polyfill lib for `Symbol.observable()`. Worst case, we copy-paste the 2 lines of code directly into our codebase just to remove that dependency. The Redux store will still implement the observable contract.
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 feeling that a lot less recently, and maybe the fact that React has been steady for 2.5 years is part of the reason.