4 ms·

Show HN: Easy State: simplified state management for React (learn in a minute)

6 points by thenewestkid 9y ago

thenewestkid 9y ago
Brief summary (from the repo): 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.
fiatjaf 9y ago
To me it seems that this offers only syntactic sugar over this.setState. No other advantage. And the cost is high: injecting a lot of magic from https://nx-framework.com/ https://nx-framework.com/ in your components.
- thenewestkid 9y ago
  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.
  - fiatjaf 9y ago
    You're right. React's own state management is something I would replace for anything else. But in my opinion the other comparisons and benchmarks don't apply, because easy-state is not a framework, just a replacement for this.setState, right? MobX, for example, does that too, in its own way, but it does a lot more than that. Maybe if you just want to write a small React app and you were going to use React's own state management, easy-state will make your life better and your components clearer, but if you're going to write something big and let some external library manage your state, then easy-state doesn't apply, right?
    - thenewestkid 9y ago
      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/examples/todoMVC 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/ 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.
      - fiatjaf 9y ago
        I will read it. What do you think is the best way?
        thenewestkid 9y ago
        This is my personal opinion. 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 (:
fiatjaf 9y ago
I don't get it. Does it use ES6 Proxies? Aren't these not polyfillable?
- thenewestkid 9y ago
  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).

6 points by thenewestkid 9y ago

Brief summary (from the repo): 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.

fiatjaf 9y ago

To me it seems that this offers only syntactic sugar over this.setState. No other advantage. And the cost is high: injecting a lot of magic from https://nx-framework.com/ https://nx-framework.com/ in your components.

thenewestkid 9y ago
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.
- fiatjaf 9y ago
  You're right. React's own state management is something I would replace for anything else. But in my opinion the other comparisons and benchmarks don't apply, because easy-state is not a framework, just a replacement for this.setState, right? MobX, for example, does that too, in its own way, but it does a lot more than that. Maybe if you just want to write a small React app and you were going to use React's own state management, easy-state will make your life better and your components clearer, but if you're going to write something big and let some external library manage your state, then easy-state doesn't apply, right?
  - thenewestkid 9y ago
    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/examples/todoMVC 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/ 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.
    - fiatjaf 9y ago
      I will read it. What do you think is the best way?
      - thenewestkid 9y ago
        This is my personal opinion. 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 (:

fiatjaf 9y ago

I don't get it. Does it use ES6 Proxies? Aren't these not polyfillable?

thenewestkid 9y ago
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).