82 karma · joined October 20, 2016
> 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.
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.
Ultimately, just give it a try and judge for yourself (: https://github.com/solkimicreb/react-easy-state#installation. It takes away 10 minutes of your life at worst case.
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.
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).
The library I made supports both of them, but I did not mention local state management for the sake of simplicity. You can find it here: https://github.com/solkimicreb/react-easy-state#easycomp (it will take 1 min to read).
Doesn't it get clumsy to pass state as props to deeply nested comps?
In a nutshell: it is used for computed properties, which compute their value on 'get' operations instead of storing them.
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 (:
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.
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.
Easy State aims to make React's state management simpler without adding new syntax. To achieve this it makes the following modifications.
It replaces React's setState() with plain native JavaScript. It auto binds your component's methods.
I am the author of the NX framework and this example. Thx for posting this here (:
The clone is not intended to be HN alternative, it is an introductory project for the framework.
The redirection issues are because of the GitHub hosting. I am aware of the possible SPA hack, but I decided against it as it would introduce unnecessary complexity to the example project. I will change the hosting soon.
The framework works in all browsers supported by ES6 proxies. (Meaning no IE and Safari 10+ only, rest is pretty much supported). The reason is the reliance on unpolyfillable ES6 proxies. It is a next gen framework that will stay in beta for some time and I hope that by the time I release v1 these browsers will have a lot smaller market share.
Thanks for the comment, I think it's pretty constructive. The site is bigger because it is a SPA. It loads every static asset on start, compared to the HN approach which loads only the current page. The NX framework itself is 12kb zipped and 10kb minzipped.
I agree, that it is not a typical use case, but it is starting to become a standard thing for new frameworks (like todoMVC). The point is to implement something that others implement too, to give a fair comparison to users (code).
About the site: It is working but things are sometimes not working at some places now because of the DNS attack (pages like GitHub and Twitter are also up and down today.)
Edit: Changed it to this. 'NX is a small client-side framework built with ES6 and Web Components. It features routing, data-binding and animations among other things.'