View profile

Rethinking State Management Libraries

Rethinking State Management Libraries
By Mastering JS Weekly • Issue #67 • View online
We’ve been thinking about what patterns we recommend for state management in Vue. We don’t like using Vuex, because Vuex suffers from the same problem as Redux and other legacy state management libs: you need to modify 9001 different files in order to wire up one simple button that sends an HTTP request in an “Enterprise-ready” way.

What Problem are You Solving?
When looking for a solution, we prefer to spend our time making sure we understand the problem rather than trying a bunch of different tools. If you look at the problem the right way, the solution is often obvious.
In the case of state management, there are 3 features that we really like:
  1. Debugging/Reloading. Centralized state means you can easily log all changes, and then refresh the page and pick up where you left off. One pattern we use often is, in development, we save the current state in local storage on every change. When you open a new page, you can hit Ctrl+O to load the state that’s in local storage.
  2. No Prop Drilling. Prop drilling is usually the first problem you run into if you try to implement centralized state without a lib. Given a property in a top-level `App` component, how do you get that property to a component 5 levels down when none of the intermediate components use that property?
  3. Cross-Cutting Concerns. Want to `console.log()` every event that happens, or log errors to Sentry? Much easier when you can tie into a stream of events.
What we don’t like is the ridiculous decoupling of logic that typically comes with state management libs. Can we get the benefits without the downsides?
Vue and Provide/Inject
With Vue, it isn’t particularly difficult to get the first 2 benefits without any state management. Create a top-level `App` component that stores `state` and provides `state` to all child components.
Merrily, merrily, merrily...
Merrily, merrily, merrily...
What about events? For basic centralized state, you don’t need them. Any component can reactively modify `state` in the above example.
Lazy state management
Lazy state management
This pattern is neat and simple, but doesn’t have a stream of events that you can tie into. That is worse for debugging (1) and cross-cutting concerns (3).
One idea we’ve been working with recently is simply providing a way to emit events, so child components have access to bits of `state` for read-only purposes, but go through emitting events to the root component for updates.
`emitToRoot()` sends an event to the root component
`emitToRoot()` sends an event to the root component
What do you think of this pattern? Hit Reply and let us know.
Looking to learn Vue this summer? Our friends at Vue School have you covered. Their Vue Components Fundamentals course is a great place to get started!
Most Recent Tutorials
How to Deep Copy an Array in JavaScript - Mastering JS
How to Install Node.js on Ubuntu - Mastering JS
How to Left Trim a String in JavaScript - Mastering JS
What We're Reading
A Guide to inject variable into your code using webpack | by Gagan Sharma | Curofy Engineering | Medium
Monitor All The Things. Here at Dollar Shave Club, our frontend… | by Jongleberry | DSC Engineering
This Dot Labs: Build Advanced Components in Vue 3 using $attrs
Did you enjoy this issue?
Mastering JS Weekly

Pragmatic web development. No bloatware allowed!

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue