Takes on State | CSS-Tricks

React is actually a bit of an outlier with state management. While it has first-class tools like useState and Context, you’re more own your own for reactive global state. Here’s David Ceddia with “React State Management Libraries and How to Choose” which does a good job of talking about the options. I say “outlier” because every other major JavaScript framework has its own blessed global state implementations.

To me, the concept of state is vital to front-end development. It’s like components in that way. It’s just shaking out that it’s a smart way to work on digital products. State is our own abstraction of what is happening on a site. It can be whether a sidebar is open or closed, a list of comments data, the details of logged-in users, or anything else that we need to draw and make functional UI.

That’s why it still feels surprising to me that native web components didn’t attempt to tackle the idea of state at all. I’m not informed enough to know why that is, but as an observer, I can see that developers are clamoring to find the best ways to make state work in and across web components. Most recently, I came across @vue/lit by Evan You. That is a microframework for web components that solves templating and re-rendering by using lit-html, and then incorporating reactive state with Vue’s reactivity. Looks pretty cool to me.

Evan’s idea takes the the combined weight of libraries in use to ~6kb. So how low can we go here? Krasimir Tsonev wrote “Using JavaScript module system for state management” where they use no libraries at all (arguably creating a small one of their own along the way). A state manager can just be a module we import and use that is essentially an Object with values, mutation functions, and listeners. That takes the overhead of state mangement down to just about nothing, at the cost of giving up the efficient re-rendering, better templating, and lifecycle stuff you’d get by using more robust libraries.

Speaking of not using any libraries at all, here’s Leo Bauza with “How does Viget JavaScript?” where they go into the vanilla pattern they use to add functionality on top of an HTML foundation. It looks like all functionality is applied via data-* attributes, and each data attribute has its own JavaScript module (Class) that handles that specific bit of functionality. It doesn’t look like the deal with global state here, but they do handle state rather manually within the modules.

I find all this stuff fascinating. In my own work, I bet I’m rather typical. If it’s a small baby thing, I might be up for a roll-my-own pattern. If it’s a medium-sized thing but sorta low-impact, I’d probably reach for the new-and-fancy — and maybe even experimental — takes. But the second I’m doing something big and high-impact, I find way more comfort in picking from the biggest players, even if that sometimes means heavier libraries. 😬

Comments

Random-User

# March 24, 2021

make sure to check out svelte stores.

Brian

# March 24, 2021

I like the approach of SolidJS

Quozzo

# March 25, 2021

React’s context is extremely versatile and is what I use for global state. It has the added benefit of being able to be used multiple times to split up all those globals states, separating the user, theme, shopping cart, language etc. So anytime an item is added to the cart it won’t needlessly rerender all the components accessing the user context.

Mathieu Huot

# March 25, 2021

Very interesting! I’m in the process of choosing a method for implementing dynamic components into a content site (static). The links here will help explore further. I didn’t find any prescribed way to do this. So far, I’ve used vanilla Js, but for more involved stuff (client area, subscriptions, etc.) I’d rather use a system I can lean on to build the application part of a site without having to maintain it myself. That without sacrificing too much performance. Still in the searching phase.

Pat+Hall

# March 25, 2021

I use data getters and setters, like this:

class MyComponent extends HTMLComponent {
  set data(something){
    this.something = something
    this.render()
  }

  get data(){ return this.something }


  render(){
    // put this.something into this component’s HTML
  }
}

Then you select my-component or whatever, and do

myComponent.data = { …some arrays and objects, usually… }

Rasmus Schultz

# March 25, 2021

I’m going to say Sinuous again. One of the things I like best about this library, is the consistent state management – you don’t need two different state management mechanisms for component and application state, it’s observables everywhere. No need to learn any patterns or switch between APIs – it just works.

Not having to choose between dozens of state management libraries in the first place, it’s such a relief.

Deepak Pai

# March 26, 2021

If you haven’t checked out xstate library, you are missing out.

Brian

Permalink to comment# March 27, 2021

Xstate is fantastic. Its visualizer is great as well for debugging / verifying your state machine logic.
Mike

Permalink to comment# April 1, 2021

React very clearly designates itself as a library for creating views and not a framework (like Angular). This is one reason it doesn’t concern itself work app state. Hell you can use React in an Angular app.

This comment thread is closed. If you have important information to share, please contact us.