As of a few weeks ago my Cursors implementation correctly `shouldComponentUpdate`s path changes as well as value changes ;)

The comment on the double setState issue on Github just cleared up a point of confusion for me:

> It might be best to think of setState as being enqueueStateUpdate

Is this why the cursor objects have something like a "pendingState" property? I can't remember the exact name, just that it exists.

That is correct. `cursor.value` always respects the react component lifecycle: this is what you always want in `render()`, `componentWillUpdate()` and other React lifecycle methods.

`cursor.pendingValue()` gives you the latest queued state update, which is always what you want in your event handlers (e.g. complicated state transitions in response to a click).

The decision is essential complexity, but at least when you use cursors the decision is mechanical. React has a slightly different API (but equivalent information) that makes the decision less mechanical.

Thanks for the comparison. And good catch with the cursor equality relying on both value and path. That is something that was recently fixed in Om.