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

Post by onesmalldrop » Mon, Feb 10, 2020, 9:19 PM UTC

adamkl wrote: post #31

To manage state in our React application, we have a "service layer", just like you’d see in a server side application, only these are based on state machines (reactive services based on RxJS observables works as well). We also created associated custom hooks that allow developers to easily "inject" a service into their React component (we use React's Context API for our "DI container"). From there developers can read…

Post by Jare » Mon, Feb 10, 2020, 9:20 PM UTC

acephal wrote: post #84

the_gastropod wrote: post #60

Earlier quoted context omitted.

I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... an…

Mmm, I work on a multimedia sequencer (timeline, viewport, etc) in the browser, it would be utter hell if the whole thing was put together via manual DOM updates in something like a Backbone View render function. I know this because when I joined the company, they were trying to do it in Backbone. For a project of that scope, this was a great way to introduce a large surface for error and maintenance (the project kic…

Post by itronitron » Mon, Feb 10, 2020, 9:21 PM UTC

bernawil wrote: post #110

itronitron wrote: post #62

Earlier quoted context omitted.

I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework. That was nice because it was relatively easy for anyone to trace through the application as needed. In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user.

In my experience if the application state is overly complex then that is a result of the design, and that usually leads to a bad experience for the user. Though it is possible to overengineer this, you're probably underestimating ho seemingly simple apps can justifiably have complex state. Say you make API calls. Your application state just grew to reflect 1. Pending request 2. Request succesful or failed 3. Request…

Post by SlowRobotAhead » Mon, Feb 10, 2020, 9:24 PM UTC

acemarke wrote: post #97

soneca wrote: post #82

Ok, only tangentially related. I would appreciate anyone more knowledgeable than me in React chipping in: Why Redux is the norm for React state management? Follow-up specific question: In which cases is it better than react-easy-state[0]? I am using react-easy-state on my company and on my side-project web apps. For me at least, it seems to add much less cognitive overhead than Redux. It is simpler to understand, sim…

I'm a Redux maintainer. There's a bunch of reasons why Redux took off: - In 2014, a year after introducing React, Facebook announced the "Flux Architecture" concept [0]. Since it was mostly just a pattern and not a library, over the next year the community created dozens of competing Flux-style libraries, which I've referred to as "The Flux Wars" [1]. - Redux came out in the middle of 2015. Its design took inspiratio…

Post by draw_down » Mon, Feb 10, 2020, 9:28 PM UTC

reggieband wrote: post #76

> 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 Inject…