In our app, datawisp.io we use observer-uitl via react-easy-state.
We have one big store where we store all of the sheets of a user, and if the user changes something, we automatically sync those changes to localStorage, and, for some of them, to a server.
However, we need to get notified somehow if anyone modifies that store. To do this, we need to have one global reaction on everything, but that's complicated, because for that to happen, every single nested needs to be touched. So, as a hack, we had introduced this pattern:
however, as you can see, that can become fairly inefficient once the object gets big. Serializing 500kb of json every time something gets touched is not all that performant, as it turns out.
So, we've changed the interface a little, so you can provide a global reaction to observable, that gets called every time something is changed within an object.
Adding a store to a store with a reaction will not work right. There's a warning for this.
No batching of any kind
You can very easily set up a circular dependency in a global reaction that prevents an object from being GC'd
I'm not sure if this should be merged into the main thing. We found it very useful, and it made our app nice and snappy
again. That said, the limitations are big, and solving esp. the first one.
So, while it fits our use-case a lot, there are a couple of foot-guns that users should be aware of.
For performance optimization.
In our app, datawisp.io we use observer-uitl via react-easy-state.
We have one big store where we store all of the sheets of a user, and if the user changes something, we automatically sync those changes to
localStorage
, and, for some of them, to a server.However, we need to get notified somehow if anyone modifies that store. To do this, we need to have one global reaction on everything, but that's complicated, because for that to happen, every single nested needs to be touched. So, as a hack, we had introduced this pattern:
however, as you can see, that can become fairly inefficient once the object gets big. Serializing 500kb of json every time something gets touched is not all that performant, as it turns out.
So, we've changed the interface a little, so you can provide a global reaction to
observable
, that gets called every time something is changed within an object.Known limitations:
I'm not sure if this should be merged into the main thing. We found it very useful, and it made our app nice and snappy again. That said, the limitations are big, and solving esp. the first one.
So, while it fits our use-case a lot, there are a couple of foot-guns that users should be aware of.