Well, that's nice. I guess the React community is aiming to try every permutation within potential state management solution space, I mean something have to work after all.
Hey Diego!<p>Nice idea and examples! Let me know if I'm wrong, but the main difference between `createContainer` and a `React.createContext` call is that you memoize inputs, correct?<p>The way this interacts with Hooks to enable state sharing is pretty cool. Hopefully someone builds a complete i18n lib on top of something like this.
Also check out react-atom: <a href="https://github.com/derrickbeining/react-atom" rel="nofollow">https://github.com/derrickbeining/react-atom</a><p>I stumbled across it earlier this week and it's a joy to use so far. The api is inspired by clojure atoms, and typescript inference works great out of the box.
Honestly I think I'm done with state management libraries. There's no longer anything I can't write cleanly with React.Context and hooks. The overhead of adding an dependency is no longer worth it.
Is there a way to use the React hook stuff without having to put the backend logic _inside_ of your UI generation code?<p>It really feels like if there was some way to put this really dirt-simple counter code into a plain-Jane Javascript object then a lot of this hand-wringing about state management in React goes away (contexts are an interesting little solution to things though)
I dont get hooks. How is this simpler than something like this?<p><a href="https://jsfiddle.net/xv7y9eoz/" rel="nofollow">https://jsfiddle.net/xv7y9eoz/</a>
Seems to solve a similar issue as <a href="https://github.com/jamiebuilds/unstated" rel="nofollow">https://github.com/jamiebuilds/unstated</a>
Maintaining state is an easily solved problem severely over engineered by frameworks. The central issue why this becomes so complicated is because developers who aren't comfortable writing original code would rather deal with an ocean of configurations than a few architectural decisions.<p>That is problematic because configurations are settings not decisions, which means you need work arounds for edge cases and work arounds for the work arounds. If instead you treat everything as a requirement instead of anything as an edge case then you are forced to make decisions and write the corresponding code. New requirements may necessitate refactoring of current decisions down the road, but the code stays clean, small, and deliberate.<p>At the most simple you only need three things: a central consolidated point of settings (object), storage (localStorage), and interactions isolated to their respective purpose (handlers).