Adding a callback to set function about cortex

[mquan]

I'm not sure I understand the use case.

1. cortex already allows you to dynamically add callbacks to the root.
2. If you need to perform side task after data updated why not do it in one of react lifecycle hooks, like componentDidUpdate

The problem with the proposed solution is you'd need a different architecture to trigger callbacks to data at levels different from root. Imagine the parent Order component can also set quantity of its child items, but provides a different callback than the set call in Item component. Or there's a decrease method in Item with its own quantity set and callback. It's impossible to distinguish these different set calls since cortex does not know how data is used.

[ivantsepp]

I think you described a good example of when adding a callback where the set function is called is more convenient than a callback on root.

For example:

var Item = React.createClass({
  increase: function() {
    var quantity = this.props.item.quantity.getValue();
    this.props.item.quantity.set(quantity + 1, function(){
      this.alertThatActionIsFrom('increase button');
    }.bind(this));
  },
  decrease: function(){
    var quantity = this.props.item.quantity.getValue();
    this.props.item.quantity.set(quantity - 1, function(){
      this.alertThatActionIsFrom('decrease button');
    }.bind(this));
  },
  alertThatActionIsFrom: function(origin){
    window.alert("The subtotal is now " + this.subTotal() + " which resulted from a click to" + origin);
  }
...

var Order = React.createClass({
  increaseItem: function(item){
    // Order can also increase item quantity but we don't want to have an alert for this
  }

If we used componentDidUpdate or cortex's callback on the root, we would need to work backwards to figure out what changed to determine if the alert should display 'increase button' vs 'decrease button'.

All this is already possible with what cortex or react provides us. I think adding a callback to the set function would be more convenient?

Not too sure about the different architecture of triggering callbacks. Would it work if we added to this payload something like payload["callback"]?

Let me know what you think! 😄

[mquan]

In your example, you have the callbacks displaying alerts, this is clearly views concern that should be handled by React. Don't sidestep React just because it's not immediately clear how to compute the diff.

There are many ways to figure out what changed, like keeping a state.changedValue or state.previousValue, or simply state.operation (plus
or minus), etc

Or better yet implement that extra logic as a sub component, AlertBox for instance, that takes data from Item and derive what to display.

Hope this helps

[ivantsepp]

Hm, I can see how there are many ways of implementing my example. Maybe this is not a good enough example to demonstrate the use case.

Let me try one more argument! I can see how one would switch from plain React to using cortex to manage data. This should solve the problem of deeply nested callbacks which call setState to update data. One would replace this with cortex's data and its set method. So, I see a relation between cortex's set methods and React's setProps/setState methods. But those methods take a callback to run when those batched state/props changes are done. Is there a way cortex can handle these callbacks as well?

Anyhoo, I thank you for your time and help! If you don't see a strong need for this, feel free to close!

[mquan]

That's an interesting idea, instead of waiting for data to be passed down, it is 'sent' to the right node. However, this means that every component must manage its own state/props and you have to supply callbacks to setState and setProps everywhere. At that point, I think you're not using React anymore. I think this approach is inferior to the current flow which allows you to pass data from the top down as props and you don't need to manually set anything since initialization and update look exactly the same.

To sum it up, I think if it's view related it should be handled by react, if it's a side task you can either hook into one of the lifecycle events or derive from the changed data. Neither of those requires the proposed callback approach, so I'm closing. Feel free to reopen if you come across something else.