When was the last time you had fun working with state? For many, the answer is probably never, because state management in JavaScript is an endless game of compromises. You can choose to go fully immutable and write reams of boilerplate de-structuring and then re-structuring your data. You can go mutable and deal with the consequences of long, fragile sequences of chained observers. Or you can just go roll your own and somehow deal with keeping things consistent across your application.
Unlike the view layer, where most frameworks agree on some variation of the component, none of the current crop of state management tools have settled on anything resembling a similar consensus. Components have a tiny API. They are functional, yet easy to reason about, and they give you a high degree of productivity for little knowledge. And while they are conceptually simple, that simplicity hides an underlying architecture geared for performance.
These factors are what make components so easy to work with and ultimately so fun to write. So why doesn’t a similar API exist for state? Why shouldn’t working with state be as easy and intuitive as working with components? We’ll be talking about this very reasonable question, and the vision for what the “component of state management” would look like.
cowboyd
nwiizo
kubode
kokushin
minhee
knakagawa
akaboshinit
odashinsuke
hanon52_
rkaga
skryukov
alquist4121
seike460
holman
trallard
jlugia
quramy
lynnandtonic
3n
shpigford
ammeep
bkeepers
trishagee
sachag
chrislema
