Things I wish I knew about state management when I started writing React apps

To me there’s nothing wrong with React, but everything wrong with people using it in inappropriate contexts.

For instance, I’ve seen a growing trend of people creating a whole DOM using React JSX so that they can use React’s server side rendering pipeline. tag all the way down. But the actual reactive components make up about 30% of the page. So you’re wasting download and JS processing time (a serious concern on low end devices) hydrating a lot of elements that won’t even ever change. It’s stupid and it needs to stop.

But for fully interactive webapps, React is great.

> Don't all of those have two-way data binding?

No they don't.

> I think the point is that Facebook found it doesn't actually work well, at least for their use cases. They found a recurring set of bugs caused by two-way data flow, and built a framework to alleviate it.

But MVC doesn't mean two-way data flow.

> but you do need to figure out how to store global state that can be accessed anywhere in your application.

Immediately I disagree and feel antagonistic towards this article.

Then the author provides an example of "prop drilling". Sounds an awful lot like Inversion of Control [1]. I've been down this road before. Next comes a Services pattern [2] (the world re-invents COM once again) and then comes Dependency Injection [3]. What he calls "global state" others have called "cross-cutting concerns" [4]. Pretty soon we'll be all aspect-oriented-programming [5] up in here.

> What you need to do is store your theme setting in a Redux or MobX store, or in a plain JavaScript object, and pass it to all your components using Context.

Yup. The beginning of a services pattern by changing to inversion of control. Once you realize you don't want all of your state on a single object you'll have `context.getUser` and `context.getTheme` and then you'll think having specific functions is a pain so you'll have `context.get(ContextType.User)`. Then you'll have interfaces so you can easily unit test with mock services.

This is all good stuff. Keep going down that road.

1. https://en.wikipedia.org/wiki/Inversion_of_control

2. https://en.wikipedia.org/wiki/Service_layer_pattern

3. https://en.wikipedia.org/wiki/Dependency_injection

4. https://en.wikipedia.org/wiki/Cross-cutting_concern

5. https://en.wikipedia.org/wiki/Aspect-oriented_software_devel...

While I'm not an old dog myself, rather a puppy. I share your sentiment. SPAs or over-jsed pages are problematic for many reasons.

At the moment this is my list when coding frontend on my own projects:

1. The less js the better. 2. If you can solve a problem in a few lines of native js, go for it! 3. Some complex "component"? Use React, it will save you a headache.

Why like this? 1. A lot can be done without js. Solutions are many times simpler and easier to modify. 2. A lot of components, like models and so on can be done in a few lines of javascript. 3. I think React isn't bad per se, many times it's a cleaner solution over native js when it comes to complex components, which can be required by designers, shrug.

Don't overthink it. Native HTML5 elements come with form validation and even a way to serialize (!) and submit form data w/ action and method attributes. (To implement the same as React components would be a 3 month project coming with a 1 GiB node_modules dir.) The only time you have to add JS bloat is for date pickers and time pickers which aren't supported on Safari yet (and you can user agent sniff for this).

Blows my mind why some people choose to adopt megabytes of dependencies when you can just write a few HTML tags and have it executed by the browser's C++ engine instead of some JavaScript nightmare.