Hacker News Reader

When has React's approach to state management changed?

The only change I know of is the introduction of the useState hook, but you don't have to use it.

The React team has done stellar job of maintaining a stable API with very minimal breaking changes. The only major breaking changes I can think of is the move of React.createClass to react-create-class and replacing the lifecycle methods through a slow and steady push over multiple major versions. I'm sure there were some smaller ones, but nothing that required any significant amount of time to fix.

As far as build systems and tooling, that's only as complex as you want it to be and doesn't have to change with the seasons. I've been using the same Webpack/Babel/React setup on one of my projects for about 7 years now with minimal work on my end (the only major upgrade was Babel 6 > 7, and Webpack 2 to 3, which took about maybe half a day to complete both).

Talking about global state management (not local state/props), when we started working with React their recommended method of state management was via Mixins. Those became deprecated in 2017 (I think). They then recommended to use only higher-order components (HOCs) for state management. Last year they deprecated this in favor of hooks. The context API has changed several times as well, though since that was never meant to be an end-user API I think it's less problematic. They also deprecated a bunch of life cycle methods (e.g. componentWillMount), though that is probably also a minor nuisance.

As you said you can still use the old ways of managing state (except mixins I think which were really removed for good), the thing is just that most of the ecosystem of third-party libraries (routing, state management etc.) quickly moves to the latest paradigm, so if you do not want to run outdated code with potential security vulnerabilities you will need to constantly refactor your code as well just to keep up with the ecosystem.

You're conflating several different things: patterns specifically recommended by the React team, patterns in vogue in the community, specific libraries from the community, and actual API changes in React itself.

The React team did definitely tell folks to stop using mixins and try using HOCs instead [0]. HOCs have some limitations as well, and hooks are designed to help address those [1], but it doesn't mean HOCs are suddenly broken and you can't use them.

React's actual APIs are quite stable. As the React team has pointed out, Facebook has something like 100K components in their codebase, and many of those are still using older APIs. For example, even `React.createClass` still works. Granted, it was moved to an external package `create-react-class` package a while back because it's discouraged, but the API still works (and that's what had mixin support).

The community jumped on render props, and the React team never specifically recommended them as a generally-encouraged pattern that I know of. The only example of render props in React's actual APIs is the `<Context.Consumer>` component.

The context API never "changed", per se. There's the original `this.context` API, which is now definitely considered legacy and deprecated, _but_ it still works fine as of React 16.x. The new `createContext()` API, added in React 16.3, is a new API that solves the same use case.

The deprecation of lifecycle methods is real, but the React team has been warning about that for a while. Note that even in future code, renaming them to `UNSAFE_componentWillReceiveProps` will still work, and the React team has provided codemods to make that fix if you want to keep using that code as-is.

The churn in the resulting ecosystem is a more valid point of concern. React-Router is a frequent target of complaints. That's _partially_ justified, as their API has changed a couple times.

As a Redux maintainer, I'm very happy that we've managed to keep the React-Redux API stable across multiple major versions and internal rewrites [2]. If you were using React-Redux v4.x, you _should_ be able to jump to the current v7.x just by bumping the package version.

[0] https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu...

[1] https://reactjs.org/docs/hooks-intro.html

[2] https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

You're conflating several different things: patterns specifically recommended by the React team, patterns in vogue in the community, specific libraries from the community, and actual API changes in React itself.

This is fair, but I'm not sure how much it matters.

In reality, we build software as part of an ecosystem. Even if the foundation of an ecosystem remains stable, much of the value often derives from what is built on that foundation. It's the other tools. It's also the blog posts and forum comments and training courses and YouTube videos. It's also the collective experience of the community in using those tools, which is reflected in all of those sources of information, as well as simply passed on from one developer to another in person.

I'm not sure React can truly claim to be stable any more, though it's certainly done better at that than many projects in front-end web development. But even if that's true, the community has moved on from the older APIs to the newer ones. The new resources are built using the new APIs and written about the new APIs. If you're still using the older version of things, even things that React itself still intends to fully support, the reality is that you're going to be excluded from many opportunities elsewhere in the ecosystem.

Why would you want to use the old APIs for new code? Surely the benefit of API stability is that your old code that you don't want to change still works? It's not like they're introducing new things every week. It's more like once a year there are major new features, and the old ones still work.

Why would you want to use the old APIs for new code?

Consistency. A code base that has been maintained for several years but now does similar things in four different ways because of which APIs were fashionable at the time each of them was implemented isn't going to be great to work with.

Or maybe you just liked the old APIs better, perhaps because they were more helpful for your particular application than the new ones, or because some other tool or library you find useful works better with the old API.

Well, I'm glad you're happy with your work, just describing my epxerience working with React over the years and the frustration of having to keep up with an ever changing flow of changing paradigms and programming styles. People value different things in frameworks, for some frontend developers it's probably exciting that the community comes up with so many new things all the time and that they can learn a new state management paradigm every year and spend time refactoring their codebase, for me it's more a nuisance.

The problem of React is not that the core API is not stable, but that it's not a full framework for developing frontend apps as it misses e.g. routing and app-level state management, it only becomes useful in combination with libraries that provide this functionality (unless you want to write your own, which is also an option). It's the rapid pace of churn in the community eco-system that's a problem for me. Probably I'm just getting old.

I agree with you about the React team being very careful about maintaining backwards compatibility as much as possible. The API is however still a moving target, and some patterns or ways of doing things are actively pushed more than others. For example you can still use mixins and createReactClass now without any problems, but the docs and tooling all have one recommended way, which slowly shifts over time.

The problem just isn't with React though, I think the problem is with the culture that expects an opensource project to always be constantly evolving and putting out new things. I'm guilty of it myself... when checking out a library in github and I notice it hasn't been updated in awhile I get suspicious of it.

And even useState is opt–in! The official documentation on hooks says there are no plans to remove classes from React: https://reactjs.org/docs/hooks-intro.html#gradual-adoption-s...

Browser APIs have changed quite a bit in the last 10 years. Yes, the same approaches are still supported, but there have been many additions and modifications to core APIs. Ten years ago you would have never dreamed of trying to build complex front end behavior without something like JQuery, but now it’s totally unnecessary as all browsers mostly adhere to the standards. I guess my point is I don’t think React has changed any more or less than browser APIs - both have just steadily updated best practices just like any other piece of software since ever.

> Browser APIs have changed quite a bit in the last 10 years.

They really haven't.

> Yes, the same approaches are still supported, but there have been many additions and modifications to core APIs.

Once again, there really haven't been.

Yes, there are many more APIs in general (audio, touch etc.), but on the whole it's the same old cumbersome poorly designed 90s-Java-style DOM API.

In 2010, browsers supporting rounded corners were considered exotic. It’s totally, totally different now.

yeah seriously... in 2010 i am pretty sure we were still rounding corners via background images in css

It's not a change. It's an addition of APIs (css in this case)

Just because the APIs remain largely backwards compatible does not mean that they didn't change. Just the fact that querySelector and querySelectorAll was introduced and started actually being usable across all the major browsers is a huge change IMHO.

I... I wrote that as my last paragraph:

there are many more APIs in general (audio, touch etc.), but on the whole it's the same old cumbersome poorly designed 90s-Java-style DOM API.

This. Framework maintenance is something that takes a lot of time from our development team. Compared to other ecosystems (Python, Java), the frontend teams spend much more time dealing with updates to their stack (webpack, react).

Once a year I update my webpack, React, and TypeScript versions. And this is for a completely custom webpack toolchain. I don't think that's unusual compared to other technologies.

> things that worked 10 years ago still work today

I have vanilla-js code from 1998 that still works unchanged in 2020.

I think the main pain point is towards front end appearance/interactions. Js as a language has gotten more ergonomic, but it's been Turing complete forever. As a practical matter, the pain comes when you say "I want to align x" and come to learn that every browser has different flags to accomplish the task. I'm sure you've seen the fat stacks of moz/ie/opera checks and flags before. I know that example is bad, but I can't think of a good one at the moment, I rarely touch front end.

That is not the case anymore. Vendor prefixes are discouraged and seldom needed.

Been using react transparently through clojurescript's reagent for years and was never hit by any of react's API changes.

The problem usually isn't react, but that most projects using it directly use it wrong.

Why refactor if you don't see any value in it? There is no reason you have to refactor.

If you don't refactor and update your dependencies regularly you can easily end-up in a corner.

You can be hit by a bug in your dependencies, be it a functional one or a security one, but if your dependencies are completely out of date and there is tons of API incompatibilities between the version you are using, and the version implementing the bug fix, it will be really painful and take a long time to update, with stakeholders breathing down your neck expecting a fix asap.

Also, maintaining old tool chains can be a real drag (maintaining older building hosts, developer machines or VMs).

Updating frequently to be near enough the latest version is generally preferable.