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
hironytic
bkuhlmann
oskmr
gotok365
kosmosebi
akidon0000
satoshi7190
fsubal
sakama
.png){kind=avatar}
elith
yosuke_furukawa
lewuathe
bryan
sugarenia
hatefulcrawdad
kastner
philnash
lara
davidbonilla
danielanewman
csswizardry
mojombo
speakerdeck
eileencodes
