4 ms·

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

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 haven't actually have seem anything about nx-js before this thread, and I liked a lot the whole approach and the explanation/argument you gave here. I'm working on something that will use xstream reactive streams and @nx-js/observer-util (previously I tried to do my own MobX-like take on observables, then I jumped into using MobX itself). I'll hope you notice it somewhere someday and give me some feedback.,
    - thenewestkid 9y ago
      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.

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 haven't actually have seem anything about nx-js before this thread, and I liked a lot the whole approach and the explanation/argument you gave here. I'm working on something that will use xstream reactive streams and @nx-js/observer-util (previously I tried to do my own MobX-like take on observables, then I jumped into using MobX itself). I'll hope you notice it somewhere someday and give me some feedback.,
  - thenewestkid 9y ago
    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.