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
twada
star_zero
heyitsmohit
tomokusaba
ogiwarat
ivargrimstad
hsawaji
hirodragon112
manfredsteyer
daisukeshinoku
pulse1923
loic425
lara
rasmusluckow
eitanlees
colly
marcduiker
paulrobertlloyd
addyosmani
ddemaree
kneath
caitiem20
tanoku
pedronauck