5 ms·

(Author here) I have added a short section to the readme describing how `react-cursor` differs from other, similar, libraries (e.g. Cortex). https://github.com/

• undershirt 12y ago
  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.
• mattdeboard 12y ago
  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.
  • dustingetz 12y ago
    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.
• caseywebdev 12y ago
  As of a few weeks ago my Cursors implementation correctly `shouldComponentUpdate`s path changes as well as value changes ;)