React controlled input have a hard time applying when updates are async about baobab HOT 3 CLOSED

@christianalfoni, you might know about this one. I cannot seem to make a controlled react input work correctly with asynchronous tree updates:

var tree = new Boabab({inputValue: null});

var Input = React.createClass({
  mixins: [tree.mixin],
  cursor: ['inputValue'],
  onChange: function(e) {
    var newValue = e.target.value;

    // If one edits the tree normally, i.e. asynchronously, the cursor will hop
    this.cursor.edit(newValue);

    // One has to commit synchronously the update for the input to work correctly
    this.cursor.edit(newValue).commit();
  },
  render: function() {
    return <input onChange={this.onChange} value={this.cursor.get()} />;
  }
});

If update is made asynchronously, the cursor will hop. Do you know a workaround? Or does the user need to commit changes synchronously?

from baobab.

Hi again,

Yeah, this might seem a bit unfortunate. I do not believe you could do anything better than using commit(). You would have to intercept and prevent the keydown, translate the key and manually update the tree which then updates the input... even that may cause some strange behavior.

But I do not think you should get into these situations. Referring to my comment on "touch". Baobab is great for flux architecture. I also ask myself two questions when creating/updating state in an application:

1. Is this application state? Does anything else in my application care about this state? Or do I think it will in the future?
2. Or is this component state? Is it only related to this component and//or its children

In the case of binding an input to a state I can not see that it would be valuable to the application to know about that "live update". Places you use binding of inputs is on typeaheads, validation in forms etc. And those are typically only related to component state.

So yeah, I would not worry about it. And as you state, you can force synchronous behavior in this "edge case", as I would call it.

from baobab.

Yes, I admit this case is quite rare. I stumbled upon such a case when building an admin for neo4j needing to have a query input synchronized with several different user interactions and archived within the localStorage for convenience.

I should probably document it somewhere and close the issue.

from baobab.