Learn where to keep your variables to improve your app design, performance, and readability.
What is State?
In programming, state refer...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Excellent breakdown! The React examples really clarify when to use useState vs const for derived state - that performance insight about avoiding double re-renders is gold.
Your progression from local → dependency injection → global state perfectly captures the decision tree most React developers face. The Context API section especially hits home - it's powerful but definitely has complexity overhead that beginners might not expect.
I recently wrote about an approach that tries to bridge that gap - keeping React state simple with atomic updates while avoiding the provider patterns that can get unwieldy. Your point about "worth the performance trade-off" is exactly the balance we're all trying to strike.
Can't wait for the actions/dispatch/reducers deep dive in part 2! The way you explain these concepts makes them so much more approachable.
State Management, and reactive state, can be tricky. And yes, with more complex cases (nested components, messaging between endpoints etc), packaged solutions can be useful.
But we can quite easily emulate things like that in a few ways - if we borrow a page from Lit.js playbook, we can use custom events to create a Context system within our HTML, if we want a simpler solution I've written dev.to/parenttobias/a-simple-obser... about building a simple Observable that can handle side effects (and derived State).
To your excellent point, I have updated the article to make it clear that Vue and Angular use the observer pattern, like event listeners. 😁
I would love to see a codepen or repo with the example from your article all together. It took me a hot minute to parse it myself, and this series is aimed at beginners. I think being able to reference it all together would help people follow along. It reads like eavesdropping on two senior developers. 💙
Yours is by far the most pleasant comment about this, so I'll address it here. Yes, you do not have to use a framework or library for reactive state or state management. Yes, you can build your own. Yes, it would behoove people to understand CSS, HTML, and JS and how frameworks use them.
However, the reality is a lot of people, including me, were thrown into reactive state and state management in frameworks without being taught the underlying concepts. That is the target audience. The series started as just a library-agnostic explanation of actions, dispatch, and reducers, because I couldn't find that anywhere.
I may add a fourth part to the series about writing your own state management, but comments railing against framework use in general and shaming people for not already understanding the underlying concepts will be hidden.
Please understand, I don't rail against frameworks. I find them practical and useful. But I really like the idea of devs gaining insight into how they do their "magic."
Thank you for your time and consideration, I'll get a codepen together to demonstrate them.
My apologies - you certainly did not rail against frameworks. I happened to get the notification about your comment in a batch of notifications. Some of the other comments were, uh, ranty to say the least.
Really appreciate how you break down when to reach for derived vs reactive state - makes those trade-offs way clearer for me.
Any sneak peeks at what you'll cover in the next parts?
Part 2
Done:
To Do:
Part 3
Maybe a part 4
Love how clearly you explain this ...helpful for devs at all levels..
This post is pure gold!
This is the kind of explanation I wish I had when I first started messing with state - makes stuff way less confusing honestly.
Never seen state described in such straightforward terms. Thanks for the lesson, this is incredibly useful!
Usually, you don't even need a fat library either. Usually, you can a) do all you need with a basic message bus or, even better, you can b) literally write your own reactive/redux-style Store very easily that scales from a—z to infinity. It is literally just 20 lines for a classical Subject (see The Observer Pattern, GoF), about 5 lines for a Store base class, and 5 lines for a base Reducer class; you can even override the main method for get/set functionality in Web Storage (+ 3 lines). The sky is the limit from there.
BTW, you don't need an L10n library either. It's like 8 lines to create that, too, even if you want to rig up The Chain of Responsibility handlers for doing advanced things like interpolation or swapping entire markdown files (with interpolations) for [example] large Terms of Agreement texts and so on. The sky is the limit from there.
You don't need a library, you need a senior. Senior Engineers keep scaling, most libraries do not.
growth like this is always nice to see. kinda makes me wonder - what keeps stuff going long-term? like, beyond just the early hype?
Thank you for such an insightful article. I see you're using a more common example among React, Vue and Angular in your article. Will you consider adding other emerging frameworks such as Astro.js or Svelte on your example for their state management?
This is just the minimum number of frameworks to illustrate all of the general concepts. As far as I'm aware, Astro's nanostores and Svelte's reactivity use slightly different implementations of these same concepts.
Nice that you wrote an article about state management! State is the evil ☠️, so it's always good to talk about it.
I'm not sure I agree with "In programming, state refers to all the variables within a program. Variables represent data held in memory."
In web applications, "state" refers to the data that represents the current condition or status of the application at any given moment.
Derived state, is not state 😄 Why? Because it can be derived from one of the variables that are needed and enough to describe the status of the app.
I'm not sure everybody thinks this: "When people talk about state in a front-end web app, they are typically referring to reactive state.". Reactive is a property of the state, applied by a pattern that introduces the abstraction, and not the state per se. React doesn't use the reactive pattern, unless you go for it with MobX, etc..., or any package that implement the observer pattern.
Anyways, glad you wrote about it! Teaching is also a learning experience, and from the discussion we both can learn! Leaving you a reading suggestion that I believe will enhance a bit your mental model on state: manning.com/books/grokking-simplicity
Thanks and keep writing! 🙏
I'm not sure I agree with “State is the evil ☠️”. State is a tool. Like any other tool, it can be misused.
You’re not wrong - state is the current status/data in a web application. And that’s held in variables. In the context of state management and when not to use reactive state for beginners, aka State 101, I’m creating an approachable mental model of “regular variables” vs “fancy/reactive variables”. You could argue it’s more of an abstraction or less of an abstraction than your framing depending on how you look at it.
I’m not sure I agree with “Derived state, is not state 😄…Because it can be derived from one of the variables that are needed and enough to describe the status of the app.” By both of our definitions, it is included under the umbrella of state. I haven’t seen anyone else make that distinction, and it seems a tad pedantic. 😄 Regardless, derived state is important to discuss in this context because I see even experienced developers putting derived state in reactive state.
You’re not wrong - I find most people don’t think the way I do. I say typically because in my experience talking to other developers, most people use “state” as a shorthand for “state that is stored in a variable with a reactive property applied to it by a pattern that introduces the abstraction, and not the state per se” regardless of the framework or reactive pattern. While you are correct that React doesn’t use the observer pattern and instead triggers a re-render and that re-render uses lifecycle events to trigger effects, I make that distinction in the derived state section. It’s still using a reactive pattern in that it reacts to changes in data (and we’re building that “regular variables” vs “fancy/reactive variables” mental model). You have hit on what I’m building towards with this series - reactive state variables are just variables with a reactive pattern applied. The only real difference between local state management and global state management is how the reactive pattern is applied and how you access the variables.
I’m glad you like the article! Hope you learned something from the discussion too. I agree teaching can be a great tool for learning. I also find that experts forget what it’s like to be a beginner. I recommend reading Why Experts Can Struggle to Teach and A Novice -> Expert Model of Learning.
Nice post!
there is a CLI named BeB you can use it to create a backend experss and mongodb project in one line try it 😁
Thanks for this article, it has helped clarify state management in React. Now I just need to remember it 😁