[zaksingh]

A big challenge with the React ecosystem is that it's the first technology many new developers work with. They don't have a frame of reference for what alternative approaches exist, and therefore 'best practices' are taken on faith and followed blindly until their nuances can be learned through experience.

That's not a bad thing (and it's better than the alternative of not caring for design patterns whatsoever). It's part of the learning process, and since there are so many beginner developers who are using React, their perspective is much 'louder' than in other dev ecosystems.

You can see this in the absurd amount of introductory-level React content posted to Medium, DevTo, Twitter, etc. This has bred a very strong 'follow-the-leader' culture where, when the one person is the room who _does_ know what they're talking about makes a statement, others will repeat it verbatim without understanding its nuances due to a lack of experience/context.

Redux suffered heavily from this. New React devs in 2017 were faced with mountains of tutorials which all used Redux. Many of these tutorials were written by other newbies. Your mental model of React dev was then shaped around Redux. Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example.

Then some React thought-leaders saw this problem and inadvertently created a counter-movement by raising how Redux was overkill for some use cases, which was misconstrued as 'you shouldn't use redux _at all_'. The pendulum has been swinging back and forth ever since.

Yes, not every application needs separation of concerns. But some definitely do. It's not black and white, and that unfortunately means there's no definable 'best practice' that can be tweeted or blogged about and followed blindly -- it just has to be learned from experience.

[codecurve]

I would go one step further and say that the counter-movement is the visible effect of newcomers discovering that separation of concerns was a bad decision for the simple apps they were building.

Or maybe more accurately, discovering that it's often simpler to separate by concern at the component level, than at the app level.

We all ride the pendulum until we find the shade of grey which works best for us.

[acemarke]

Agreed on all counts.

Like, I don't want _everyone_ to use Redux. I just want people to understand "here are the strengths, weaknesses, and use cases of tools X, Y, and Z, and when it may make sense to use them".

Honestly, we Redux maintainers (Dan, myself, Lenz Weber) have had to spend far more time telling people when _not_ to use Redux than we have trying to advertise the library :)

When I rewrote the Redux docs tutorials last year, I made it a point to put "When should I use Redux?" right up front on the first page:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

but that sadly can't have any effect on the thousands of existing tutorial pages or low-effort posts that are out there already.

[anchpop]

> Therefore you would put everything you could into the Redux store, which is a bad idea -- you usually don't need form state in there, for example.

Why's that? IME it is usually simplest to just put everything in redux. For example, if you have a form under some kind of tab navigation thing, you'd ideally want the form state to be preserved even when they tab out and then back in. Putting it in redux means you don't really have to think about it

[Jcampuzano2]

But this could also just as easily be solved by moving the form state up, or at least the preservation of each tabs state one level up, without using redux at all.

You'd still preserve on tab change just as easily, while using just reacts mental model.