
Show HN: Easy State: simplified state management for React (learn in a minute) - thenewestkid
https://github.com/solkimicreb/react-easy-state
======
fiatjaf
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
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
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
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/...](https://github.com/solkimicreb/react-easy-
state/tree/master/examples/todoMVC).

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
I will read it.

What do you think is the best way?

~~~
thenewestkid
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
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
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.

------
thenewestkid
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
I don't get it. Does it use ES6 Proxies? Aren't these not polyfillable?

~~~
thenewestkid
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).

