[frigen]

I agree that reactjs would have been better without setstate, instead with tightly integrated Redux, which would remove much of the Redux boilerplate.

For the most part, this is what this reframe thing aims at as far as I can tell.

Setstate really should be long term deprecated, it's a design error in react.

[mercurial]

No, it's really about knowing what is global and what is local. You have plenty of things for which local state makes sense.

[frigen]

True, but ideally the framework would lead programmers automatically to ways of doing things in the "right way" instead of overusing local state.

A "better react" would make it natural and obvious to use store versus local state in the appropriate way.

[mercurial]

Well, that's not really the idea behind React. You could say local storage is more a convenience than anything, React is primarily about rendering your data.

The problem is that, with Redux at least, composing data stores is a major pain. The only pattern supported out-of-the-box is horizontal slicing (have different reducer for separate pieces of data). This may work for separate pages, but it does nothing for you as soon as you need data sharing. I don't think React itself should change, but I haven't found a really satisfactory solution to the problem of sharing stored data.

[rmrfrmrf]

setState has its uses, especially for things like "time from now" displays where the model doesn't change but the display needs to.

[simoncarter]

I agree, and try to write all my react without it, using redux, thunks and reselect heavily.

I think it's easy to say it was a design error with hindsight. I'm happy React came along, and in the future it will either get better or we'll move on to something else, heaving learnt from it's mistakes.

[frigen]

My theory is that any technology that can be simpler will be replaced by one that IS simpler.

New technologies like react either need to fix their problems like lack of integrated state management or be replaced by something that does do it right.

The criticisms of the linked post are valid.

[chrisweekly]

I read your 2nd sentence as "the view library needs to become a framework".

Integrated state mgmt is out of scope for React JS per se. Some ppl feel mobx is a better approach than redux. They're free to mix n match libs to suit their prefs. The React ecosystem is a set of libraries; by definition that entails more choices, more "fatigue", more combinations of approaches, and more innovation, compared to all-inclusive frameworks like Angular. Don't get me wrong; Ng gets some things right, and there are valid reasons to deliberately limit choices and go all-in w/ a framework. But I respectfully disagree thst React "needs" to integrate state management.

[tessierashpool]

> My theory is that any technology that can be simpler will be replaced by one that IS simpler.

This theory is correct. It explains why virtually nobody ever uses C, let alone C++, and all of our internet infrastructure is built on top of Scheme.

[taeric]

This flies in the face of the proliferation if js frameworks.

Mayhap each simplified something, but the result is more complex. Frighteningly so.

[BigJono]

That's a symptom of people not understanding the concept of complexity and falling victim to the law of leaky abstractions.

People don't work towards reducing complexity in large applications (which involves trimming dependencies, removing api surface area and minimizing interactions between different people's code, which is all hard), they work towards reducing complexity in simple toy applications (which is about cramming as many tools in until you can do exactly one specific thing in one short line and it looks nice).

That has the effect of reducing complexity at first glance, but increasing it in real world applications.

[taeric]

I was playing with that thought in my head. Would be neat to highlight some examples of good simplifications.

Databases come to mind. Collections libraries do not. :(

[qudat]

Totally disagree about `setState`. Even with redux it still is very useful.