(update) The discussion here has convinced me; I have opened an issue to eventually change the nomenclature.

The most common use of cursors will eventually bind them to React form components. Cursor's value/onChange interface is meant to directly line up with React form components' value/onChange convention. That said, I get asked this question a lot, perhaps mostly by people who aren't already React developers.

Coming from someone who has used React.js a lot, I found the name unintuitive as well. Would've expected a variant on setState. That said, this library looks extremely useful and I can't wait to try it out in a project -- thanks for publishing it!

onChange is a synthetic event which is part of React (and also used in Om of course). http://facebook.github.io/react/docs/events.html

I know about onChange for events on elements. But what exactly is it doing on the cursor? onChange in react allows you to provide a callback when things change. But that doesn't appear to be what is happening with the code samples in the read me.

For example

cursor.refine('b').refine('foo').onChange({ 'bar': 43, baz: 56 })

What is this doing? If onChange isn't transact, what is the react-cursor equivalent?

I agree, the naming is odd. `onChange` is almost always the name of a function that is called by a user event and passed an Event object, not called by the programmer and passed a raw value. Is it supposed to be used as the first line in a form onChange handler? Perhaps something like

    onChange: function(e) { this.cursor.onChange(e.value);}

Even in that case, I think it is a lot more intuitive to use a function name like `change`, `mutate`, or `transact`. Personally, `onChange` is something I want to assign, not something I want to call. Additionally, it doesn't look like it can be passed a raw Event object, so you can't shorthand it in a render method and avoid creating an onChange callback.

I agree. The first minute I looked through the tutorial `onChange` confused me, because I expected it to take a callback.

I would prefer `transact` or any other of your proposed method names over onChange.

Oh, huh. Good question. That does seem a little strange.