My Small test about mobx HOT 7 CLOSED

Interesting case!
I'll try to dive into it more deeper later today, but at least in the setSP function you should be able to do:

mobservable.transaction(funtion() {
    x.stock = newStock;
    x.price = newPrice;
});

that might save some updates.

from mobx.

Wonderful. It is working (only had to update the setSP function as you described ).

Since you find this use case interesting, maybe you could tell us whether this approach is good. Maybe there are better ways to "sync objects" using mobservable?
I'm also thinking of syncing objects across VMs and across machines (over the wire)

window.setSP = function(x, newStock, newPrice){ 
  mobservable.transaction(function() {
    x.stock = newStock;
    x.price = newPrice;
  });
}  

from mobx.

Now that I think of this, this is exactly one of the situations a had on my todo list to forbid :-P.

The problem is that the side effects are not pure; they are updating the state their own execution depends on. In this case it works, but in more complex situations it can easily become hard to reason about and error prone; for examples, if the code would contain x.price = newPrice + 1, it would probably start to loop. Also it is harder to optimize.

A clean way to solve this would have a central stock and price state, and just derive the others from it:

centralState = mobservable.makeReactive({
  stock: 0,
  price: 5
});

wareHouse = mobservable.makeReactive({
  stock: function() {
    return centralState.stock
  },
  price: function() {
    return centralState.price
  },
  setStock(newStock) {
    centralState.stock = newStock;
  },
  setPrice(newPrice) {
    centralState.price = newPrice;
  }
});

That would completely avoid the need for the side effects. The set functions can probably be turned into ES5 setter for more convenient invocation.

But it depends on your use case whether you want to have such a central state. Would the above solution suffice for you? If you are creating a distributed system, the original solution makes sense and will work (and keep working), because it turns the problem in an asynchronous problem. But again, beware of unending loops in such case. But within a single process, data should either be derived data, or mutable state, but not both at the same time. Just to ease the mental model of your app.

from mobx.

Thanks.

I thought of the 'loop' problem and I'm fine with it (it could happen if the syncing between objects does some rounding so that the "declared equivalence" between the objects will never be 100% met).
Is there any other potential problem in the above approach?

I thought of having a 'star topology' but it'd be better not to have to sick to any particular topology. Furthermore, to the best of my understanding the code you provided above still need something like 'mobservable.transaction' to avoid triggering changes more then the "absolute minimum number of times". Also, wareHouse is aware of the centralState (i.e. tight coupling).

In the best of worlds. I'd have objects that are totally unaware of each other and all syncing happens with the help of an "external broker" in the minimum number of steps 🎱.

from mobx.

Yeah I can definitely see your use-case. I think the safest way to protect against looping is to update a version number upon change or distribution, and check whether your already up-to date before applying changes.

I'll close the issue for now, but don't hesitate to comment if new issues arise.

from mobx.

One last comment if you will. Should I conclude that the approach I've chosen is good to go?
PS: Indeed I will have to use versioning to avoid extra steps or even infinite loops.

from mobx.

Yes, this a valid approach for a distributed system :) For just local
system I think it is recommendable to stay with 'one truth'.

On Fri, Aug 28, 2015 at 12:00 AM, mehdi-cit [email protected]
wrote:

One last comment if you will. Should I conclude that the approach I've
chosen is good to go?
PS: Indeed I will have to use versioning to avoid extra steps or even
infinite loops.

—
Reply to this email directly or view it on GitHub
#22 (comment)
.

from mobx.