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

  They're forms that submit stuff to a server and get a response

a. json

b. SSR-html?

If,

a. Now you've got to process that response, handle errors and finally render into html. You'll be either imperatively replacing DOM nodes, interpolating string templates or both. Probably re-binding event handlers after that.

b. You'll be merging your server-rendered html to your current view. Re-binding event handlers if you've got any interactive stuff (e.g your SSR came with a modal link) and god knows what else.

React is a million times better than this.

I asked something like this too, but the other way around.

"If Flash, Delphi, etc. were so good, where are they now?"

The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.

macOS/iOS is a good modern example of the old way of doing things where you're stuck using this weird OOP-for-OOP's-sake Core Data abstraction that certainly doesn't feel like a local optimum. It's the polar opposite of simplicity. When things don't work, it gets complicated very fast as you try to credentialize in it.

By the way, client development was never easy. It's only gotten simpler over time. Painting a component to the screen (your example) whether you can use a built-in or have to make your own is still the easiest part of client development, not the hard part. State management and deciding on when to repaint is still the hard part. And just because the runtime gives you a solution doesn't mean it's simple or ideal. So I'm wondering which specific client development experience you're looking back on with such rose-tinted glasses.

Jesus don't do this. Mobx, Vuex, Redux, etc, are about managing application state not about managing application logic.

I started making SPAs in 2015 and I also used actions for everything (API calls, auth, etc). It was fine for small projects but then I got to work on a medium sized project and those actions became huge and controlled everything in my app. I usually consider myself a pragmatic person but that was impractical for a number of reasons and also conceptually wrong.

When working in SPAs now I remove anything that is not state management from MobX/Vuex/etc (I don't use Redux anymore). That logic belongs somewhere else.

The pattern I'm doing now is that I conceptually separate components from the application logic. The store(s) feed data to the components but if the components want to interact with the application they go through a mediator of sorts (eg: changing a route, modifying state, authenticating, etc). This mediator then interacts and coordinates with the different application modules.

For example when authenticating many things have to happen in different modules (API, store, router):

1) An API call has to be made to verify credentials and receive a token

2) This token has be stored somewhere eg: localStorage

3) Maybe we also need to make an API call to get user info, their roles, etc

4) Some state in the store has to be modified. Not only the user info, but the app logic usually needs to know if a user is authenticated.

5) We need to tell the router to go to somewhere eg: /home

It makes no sense to do all that in an action. Store actions should be about managing state, period.

  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.

Say you make API calls. Your application state just grew to reflect

1. Pending request 2. Request succesful or failed 3. Request result or error 4. Finished request.

Redux apps track all of this explicitly. The alternative to this is not reducing statefulness. It's just ignoring it with all the brings.