Hi, I'm encountering some trouble with react-cursor. The bug that I'm encountering is in a relatively simple component where I add/remove items from a list. The bug manifests itself in many ways. The simplest is that if I add an item to the list and the try to remove it, the item will not be removed.

When I attempted to debug this by looking into what react-cursor is doing, it appears that the memoize function calculates the hashed key for the new state, in which there are no items in the list, and then checks to see if the hashed key is already in the cache variable. Strangely, the hashed key for the component state with items in the list is the same as the new state without the list, and so the memoize returns the previously cached component that still has the item in the list.

I've been trying to debug this myself, since I'd like to contribute to your project, but have hit a bit of a wall. From what I've found it seems as though there could be a problem in the hash function such that it returns the same value for two different strings. Any suggestions?

One real world issue we have run into, is that when React state is conceptually at the top, but actually it isn't at the top because there's non-react portions of the system above it, engines above it etc

As of React 13, cursor doesn't need to use a react private api anymore, because of the improved setState api. So Cursors really only depend on two things conceptually: a setState function, and a current state value. It doesn't actually have to be a React component anymore.

So given this, I believe I could implement the setState/value api outside of react and backed by regular javascript objects, thus cursors can be constructed above the React entry point. This is analogous to the model provided by other cursor implementations (ImmutableJS and Baobab), except it keeps the benefits of react-cursor over those approaches - namely, simplicity of code (a lot fewer lines of code), and simplicity of types (no special immutable types, just regular javascript objects)

Could be worth exploring.

Since shouldComponentUpdate is hot code, I figured it'd be worth optimising it by paying some readability. This PR therefore...

• simplifies refsChanged checks if we just have a single ref field
• simplifies valuesChanged if we aren't ignoring any ref fields
• preruns the ignore union
• minimizes object lookups
• only calculates refsChanged if valuesChanged wasn't true
• minimizes function calls

Object.isFrozen throws an exception when called with 'null'. Use an isObject() function that tests for null.

Also, ignore functions because they can have recursive members (e.g. constructors).

As of React 0.14, each addon is moved to separated package, in this project, install react-addons-update separatedly and enjoy it.

This is one more step to decouple with React. :tada: :tada: :tada: :tada:

During my plays with react-cursor I've often wished I could delete a cursor, removing it from its parent (if it has one). Or am I misunderstanding something in barking up this tree? Say for example we wanted to add a delete button to the Clicker components in the helloworld webapp example. Is there a better way to do that without my imaginary delete API?

Prevents #47. I'm not entirely convinced that it's possible to detect out-of-band mutations. I haven't thought it all the way through.

One idea, is that the cursor update methods (set, push, etc.) can hang on to a reference to the final value right before they pass it to react setState. Then in each subsequent invocation to a cursor update method, we can recursively check that the current cursor.value is reference-equal to the previous value at all nodes of the tree, before performing the update. This would have performance implications.

I removed underscore as an dependency by adding small dependencies (without further big dependencies just the necessary functionality: union/equal/omit) or own implementations. In most places the ES5 functionality is used and polyfilled if not available by Mozilla's polyfills (see polyfill.js). See commit 3b33b74.

onChange is still available for backwards compatibility, but if Cursor.debug is set to true warnings will be emitted, that should help tracking down uses for a flawless transition. The new method set is available providing the onChange functionality without the warnings (see 6f8e569). This commit also contains preparation for additional functionality like push/merge updates.

At last I rebuild both the example and dist and increased the version number to 0.9.1 (see 0bd60f2), which means if the pull request is excepted a new version needs to be pushed to npm.

Relevant issues: #10 #9 #6

As with programming, it is usually a good idea in language to use the simplest possible solution. Is there a way to communicate what is meant by orthogonal with a more easily understood word? Do you mean that react-cursor and Flux represents opposite approaches?

One of the things I miss from Cortex is the ability to use map(), filter(), find(), findIndex(), and forEach() on cursors over lists and keys(), values(), and forEach() on cursors over hashes. These should work like their native equivalents but their return values should be cursors.

For example, I want to pass the currently selected item in a list of hashes down to a child component. The currently selected item is identified by having an attribute selected set to true:

var selected = this.props.someList.find(a => a.selected.val());

With react-cursor, I (think I) have to write:

var _ = require('lodash');

var selectedIndex = _.findIndex(this.props.someList.value, a => a.selected);
var selected = this.props.someList.refine(selectedIndex)

We seem to have operations to mutate the cursor, but only value for accessing it.

React.addons.update supports more than just $set, we could easily expose these functions. http://facebook.github.io/react/docs/update.html

It would increase the API surface area from four methods to nine.

Say something here if you have an opinion.

A lot of people prefer component-local state over cursors because of the intuitive performance cost of trickle down rendering.

How might we cause a derived cursor to forceUpdate it's react node, causing a render directly instead of trickle-down rendering of nodes in the path from root to node? Is this possible?

The problem is that, React state has getInitialState, so the default state can be defined inside the component. With cursors, the default state has to be declared somewhere else, at the top.

So suppose refine could take an optional extra argument, a fallback value

state = {a: {b: null }}

cursor.refine(['a', 'b']).value //=> null var not_found = {c: {d: 42}} c2 = cursor.refine(['a', 'b'], not_found); c3 = c2.refine(['c', 'd']); c3.value //> 42 c3.set(c3.value + 1); //> {a: {b: {c: {d: 43}}}}

I did implemented this in clojurescript and I found this helped clean up my components quite a bit.