Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cursors #42

Closed
wmertens opened this issue Mar 11, 2015 · 4 comments
Closed

Cursors #42

wmertens opened this issue Mar 11, 2015 · 4 comments

Comments

@wmertens
Copy link
Contributor

I'm writing an app with Fluxy and the Cursor concept would be handy. Om uses it, so I presume there's something for mori, and Immutable has https://github.com/facebook/immutable-js/tree/master/contrib/cursor.

I'm thinking that a get() from the store should in fact return a cursor so that any changes to the value are reflected in the store. That way, instead of doing things like Store.set(Store.get(id).setIn(path, value)) you simply do cursor=Store.getIn([id].concat(path)); ... ; cursor.set(key, value) and the store would get the change notification.

You'd pass subcursors to your composed elements, so they only need the cursor, not the store, id, and path.

I'm ok with doing the work for Immutable but I suppose that the API has to match the mori one. Anyone with experience?

@jmreidy
Copy link
Owner

jmreidy commented Mar 11, 2015

I don't think there's a good cursor solution for Mori yet. There's an [open PR(https://github.com/swannodette/mori/pull/108) that exposes the functionality, though.

That said... as much as I like cursors (I'm a big fan of baobab's approach), I'm not convinced they work well with Flux Stores. I think the two approaches are more alternatives than complements. But I'm open to being convinced otherwise. :)

@wmertens
Copy link
Contributor Author

On second thought, all I needed to do to implement it is add a getCursor(path) method on my store class which calls this.set in its update callback. It also required importing the cursor class, which is small but still sad for people that don't use it.
So I'm closing this, it's too easy to implement yourself and you might need custom logic in the update callback anyway.

@wmertens
Copy link
Contributor Author

BTW, the cursor works great in my case because I'm storing a big recursive object that I need to walk through for displaying. See the first comment for how it simplifies updating. So it's definitely something to keep in the toolbox.

@wmertens
Copy link
Contributor Author

One pitfall for future reference: When the cursor is updating, you shouldn't apply the change to the cursor data. Simply pass the change on to the store and wait for the redraw.
That way, cursors point to stale data and you can compare them in shouldComponentUpdate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants