Easy State is a minimalistic transparent Proxy based React stage management library with a stronger focus on practicality than code beauty. V6 added sync render batching for common task sources to improve performance.
Complexity wise it is much simpler than Redux in my opinion, but its like apple to oranges. It is closer to MobX in philosophy and it is simpler, in exchange of narrower platform support.
It was nice to randomly find your name here (: Good luck with the interviews, I totally agree with your points. Your blog improved a lot since I last checked it! (The NX framework guy)
Author here. As sigden mentioned, ES6 Proxies can not be transpiled. That is one reason why they are not yet commonly used. You can find out more about them here: https://developer.mozilla.org/en/docs/Web/JavaScript/Referen... (They are pretty awesome).
No, I have never used Vuex, but I think Vue is an awesome framework. My main inspiration was monitoring my problematic situations and state management needs during app development in various frameworks.
Sure, I know about MobX. I use ES6 Proxies instead of the getter/setter based transparent reactivity they use. It allows me to have less edge cases in exchange for narrower platform support.
MobX is also moving in the Proxy direction with v4, but I do not agree with some of their architectural decisions (mostly the synchronous execution), so I made a separate library. We can discuss these later if you are interested.
Valid point. You can move that logic to the component and leave the store for pure data manipulation and handling only. I do that for bigger projects, but in this case I wanted to make things short.
The goal of this series is not to teach patterns but to promote a simple and flexible stack that you can use with the patterns that you like. (In your case you can move the view specific logic to the level of the components).
React Easy State is a simple library, which provides balance between local component state and global stores. It uses a modern version of transparent reactivity (similarly to MobX) with ES6 Proxies under the hood. Please check it out and give some feedback if you have can (:
Easy State provides a healthy balance of local and global state management in a simple, scalable way. It consists of two functions only with no hidden complexities. Please give it a try if you have 5 minutes to spare (:
Great, I would be happy to check you library! Just send a link here or pm me on twitter (@solkimicreb1) when you can share it.
PS: your argument about MobX got me thinking. I decided to add a new function to v2, that creates MobX like external stores for handling global app state more elegantly.
Structure wise: Having a singleton app store and separate component states together is the best pattern. Hidden details of a component's functionality should go into its own state. App level data (like the current user) should go into the single app state. Also the minimal set of state that defines the other part of the app state (typically state props from user input) should be two-way reflected in the URL or local storage - depending if its a shareable state detail or user preference.
Timing wise: Synchronous view updates (MobX approach) cost too much performance wise. It is often also not in align with the natural expectation of the developer. (Even MobX has actions, which is just async execution with a bit more granularity). React's approach is a bit too lazy for my taste. Updating the state asynchronously leads to confusion and has no benefit in my opinion. Synchronous state update has practically zero performance cost compared to view updates. Updating the state synchronously and the view asynchronously - but always before the next paint - seems to be the best approach for me. You will never extract existing state from your view and from the user's perspective the only important thing is to have it updated before it is rendered.
Data management wise: I think it is super important for a reactivity library to do not save or alter any of your state. It should just save reactions paired with data mutation/access points. Saving data can cause staleness and mutating your data behind your back is just a mess. I was super careful to leave you objects untouched (opposed to array hacks, hidden getters/setters and memoizing your own getters/setters (computed values)).
In the end Easy State is most similar to MobX. It just saves reactions (renders), which it triggers on state/store mutations. The biggest difference is in its timing (async vs sync), minimal syntax and (in my opinion) fewer edge cases. The difference between using the state vs an external store is pretty much a one line change. They are both normal observable objects, they are just in different locations with different names.
Sorry for the long answer. No worries if you don't have time to read it (:
Edit: I also dislike 3rd party injection libraries (like the MobX @inject decorator). Simple ES6 imports should be enough for injecting the single app state and props should be enough to pass down a component's own state. Angular is a prime example of how more complex injection systems can go wrong. This is just my opinion though and it even might change in the future (:
You are right. It does use ES6 Proxies and they are not polyfillable. IE and React native is not yet supported because of this (it's mentioned in the platform support section).
I understand why you might feel like this, but don't judge too quickly (; Easy State can do (pretty much) anything MobX does. It just does it in the background without the extra explicit syntax (observable, action, observble modifiers, etc). You can easily use it like MobX (with an external store) if you do something like this: https://github.com/solkimicreb/react-easy-state/tree/master/....
If you are interested in a MobX vs nx-observe (the library behind Easy State) comparison check this (rather old) article: https://nx-framework.com/blog/public/mobx-vs-nx/. Let me know if you think that it lacks some important features.
Thx for the response!
Edit: it would take a rather small modification to make Easy State work like MobX, but I think that it is not the best way. In the future I could add a @store export for making MobX like stores though.
I actually think that simpler syntax is a big win. See the key features section for the other advantages (no async issues, optimal shouldComponentUpdate).
About the cost: see the performance section for a third party benchmark. I think you might mean hidden complexity by cost. In that case why would this be more magic than React's own state management? Both are just JS code in the end, and I can assure you I did nothing very hackish under the hood.
Yes, it is a GitHub hosting issue and it works when the project is run locally. I am aware of the GitHub SPA hack, but I decided against it, since it would introduce unwanted complexity. My main goal with the repo is to teach how to use the NX framework.
> It doesn't matter how you structure or mutate your state stores, any syntactically valid code works.
In this article, I try to prove this with a simple app and increasingly exotic state structures and mutations.