23
On state management and why I stopped using it
In the front-end/Javascript world, there was once a time when state management reigned supreme. The dominant player was Redux, primarily used by React developers.
State management has (had) a purpose. It allows you to do things like going backwards and forwards throughout the history of the state, convenient for instances where you need some kind of undo functionality. It can also help you understand what is happening inside of your applications thanks to time travel debugging.
The biggest downside to state management is boilerplate. Once you do the initial setup of your state management, you can have to adhere to the paradigm of the state library you are using. You need to familiarise yourself with concepts such as reducers, actions and other terms that might not be familiar to newcomers.
Then comes the buy-in. You have to change how you structure and write code to use state management solutions like Redux. This means if you want to change to another state management library later on, you have to go through your app and change over every instance. It's rare that any two state management libraries are alike.
With this buy-in comes lock-in meaning once you commit to state management, it's all or nothing. While there is nothing stopping you from intermixing state management with other approaches, conflicting paradigms null the whole point of even having state management in the first place.
As someone who has had the unfortunate job of tearing state management out of a large-scale web application recently, I can tell you that it is torturous.
If state management solutions existed which were able to be included like jQuery and bam! I have state management, maybe it wouldn't be an issue, but architecting my apps around a library that might be deprecated or obsolete sounds like a maintenance nightmare.
I cringe every time I see state management being shoehorned into simple forms and I have never seen it done in a clean and unobtrusive way. Almost every state management solution I know of has a forms plugin, the fact you even need an additional plugin says all you need to know: don't use state management for forms if you can avoid it.
When dealing with form data, in most cases you are dealing with ephemeral state. A login form only exists until the user logs in, the data is sent to the server and then that's it. If you're using React, use useState if you have too, but making Redux or X name library bend to your will to have a username and password in your state seems like a waste.
In some cases, you might have form-based data that flows over multiple steps. Think of a signup screen where you need to guide the user through steps and then submit at the end? That's a valid use case for state management because you're effectively filling out a large object of data. Still, you could probably use something less complicated to achieve the same thing.
Please, for the sake of everyone else around you: stop using state management for loaders and modals. I swear, almost every web application I have seen using state management has loader states and other booleans in state management for the stupidest of things.
I'm sure you've seen isLoading used more than once or a boolean for showing and hiding a modal before.
The age old problem of cache invalidation. I've seen state management used and abused as a form of data cache, fetching some kind of data from the server and storing it locally. Sometimes data doesn't change, but if you're dealing with data that can or will change, invalidating it is another story.
Do you know who solved data caching and invalidation a long time ago? Web browsers. Sometimes a good old fashioned GET request and some properly defined headers is all you need to cache data in your application and have it update when it changes.
Once again, there are solutions out there for these things in state management too. Redux has a trove of plugins that address its shortcomings, for example, but can you imagine buying a car and then continually having to add to it to drive on different roads?
My advice to anyone starting a new project whether you are using React or Svelte, don't be so quick to reach for state management. It still has merits, time travel debugging and the ability to undo/redo state changes are features I love. But more often than not, you're dealing with data that shouldn't be in state in the first place.
When you use state management I often say, it's like you're building two apps at once.
23