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
yuisakamoto
suzukihoge
javiergs
pyama86
ivargrimstad
taro28
tasshi
ymtdzzz
kakao
tsucchinoko
little_rubyist
riofujimon
vanstee
andyhume
eileencodes
notwaldorf
honnibal
rocio
chriscoyier
aleyda
garrettdimon
brianwarren
davidbonilla
morganepeng
