dustingetz

react-cursor

JavaScript2014–2017

dustingetz / react-cursor · Archived

react-cursor

Immutable state for React.js

Web Development

Explore on GitHub Read Hacker News discussions

4Distinct people

19Mentions

1Explicit recommenders

1KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Immutable state for React.js

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

I am the author of react-cursor, which abstracts over the react immutability helpers[1], which I have used in four large projects. It scales great and I recommend it over…

dustingetz used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

wingspan/wingspan-forms · linked in 3 of the same discussions
hyperfiddle/hypercrud.browser · linked in 2 of the same discussions
mobxjs/mobx · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 6:01:08 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year19 dated mentions

Observed mentions: 2014-07-21 19:26:03 UTC to 2017-11-01 16:13:38 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Submissions	Comments
2014	2014-01-01 00:00:00 UTC	2015-01-01 00:00:00 UTC	9	1	8
2015	2015-01-01 00:00:00 UTC	2016-01-01 00:00:00 UTC	6	0	6
2016	2016-01-01 00:00:00 UTC	2017-01-01 00:00:00 UTC	1	0	1
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	3	0	3

What Hacker News says

6 sources

curveship·Dec 17, 2015

It looks like react-cursor is 1300 loc [1], mobservable is 1900 [2]. How is that "vastly less code"? 1 - https://github.com/dustingetz/react-cursor/blob/master/dist/... 2 - https://github.com/mweststrate/mobservable/blob/master/dist/...

In RxJS is great. So why have I moved on?

dustingetz·Dec 17, 2015

That looks to me, a lot more complicated than it needs to be. I think that has combined two separate things - atoms and cursors. Here they are in javascript: https://github.com/cjohansen/js-atom/blob/master/atom.js https://github.com/dustingetz/react-cursor/blob/master/src/C... Vastly less code than https://github.com/mweststrate/mobservable/tree/master/src. Cursor+Atom has nothing to do with Rx or core.async, of course, and is probably not the future. (I say this as the maintainer of react-cursor)

In RxJS is great. So why have I moved on?

dustingetz·Oct 5, 2015Recommendation phrase

I am the author of react-cursor, which abstracts over the react immutability helpers[1], which I have used in four large projects. It scales great and I recommend it over full-on action-store-dispatcher flux (redux and the rest) for almost all projects except the very largest (like multiple frontend teams). Action-store-dispatcher is less direct and has an abstraction tax compared to just connecting views to state directly. A React.js lead even just wrote on twitter [2], "Starting to see a trend of premature fluxing of react apps. Try plain @reactjs first and bring in flux only when you absolutely need it." Here's a screenshot of a pretty big project that scaled great with cursors: http://curator-lilita-10664.bitballoon.com/work-area-metadat.... We had all sorts of complexity scaling problems while building this, but none of them were due

Read the rest

to state management, migrating to cursors made 99% of pain due to complicated ui state go away. [1] https://github.com/dustingetz/react-cursor [2] https://twitter.com/floydophone/status/649786438330945536

In Immutable Data Structures and JavaScript

dustingetz·Aug 14, 2015

> I’d recommend the immutable-js library for it. It has nice API and it comes from Facebook itself. Another option is the baobab library - but it works better when more ‘reactish’ ideas are present in your codebase, like global app state. Another option is a library I wrote, react-cursor[1], which is basically sugar over the React immutability helpers[2] which the article mentioned. react-cursor has a couple advantages over immutable-js and baobab: 1/ simpler types: use regular react state with plain old js data structures, 2/ simpler implementation - about 100 lines of code and tiny api, 3/ super easy to integrate with your existing large codebase already using react state [1] https://github.com/dustingetz/react-cursor [2] http://facebook.github.io/react/docs/update.html

In Pros and Cons of using immutability with React.js

hakanderyal·Jan 22, 2015

The method that you linked is the one I use currently. Another way is to use a nested immutable data structure (something like immutable.js[1], react-cursor[2]), use only one store, and make all changes on this data structure and pass accordingly. Even if you don't use immutable.js, I strongly suggest to use immutability with react update[3] or equivalent. Things get way easier that way. [1]: https://github.com/facebook/immutable-js [2]: https://github.com/dustingetz/react-cursor [3]: https://facebook.github.io/react/docs/update.html

In Marty.js – A JavaScript library for state management in React applications

eric_bullington·Jan 21, 2015

Great comment and excellent intro to React for interested devs. I've been successfully using React for small and mid-sized apps, and agree that Marty looks like it's an elegant solution to the Flux pattern. (for application state in React, I've also had some success with passing around an immutable cursor, like react-cursor[1]). One cautionary note about how easy it is to integrate React with other frameworks: this statement is true as long as the framework in question doesn't touch the DOM (e.g., using Backbone models). But if you try to integrate React with any JS library or framework that mutates the DOM, you should be aware that this will interfere with React's DOM "accounting" and potentially cause lots of problems. There are certainly ways around this (look into the lesser-used React life cycles), but it's much easier to stick w

Read the rest

ithin the React ecosystem for any libraries that manipulate the DOM, or build your DOM manipulations from scratch (easy to do with React). Already, there's a fairly feature complete React Bootstrap library [2]. I've started work on a React charting library, using d3 for path calculations and other utilities (and temporarily for chart axes generation, but library users shouldn't have to worry about any DOM issues) [3]. And I'm sure there are a thousand and one other React view-level component libraries I'm not familiar with, most of which are likely available via NPM. But I agree that React and the other virtual DOM libraries and frameworks (Ractive, Mercury, Om, etc.) are the next generation approach for client-side views. They not only make DOM manipulations much snappier, but they also make them much easier for the developer. 1. https://github.com/dustingetz/react-cursor 2. https://github.com/react-bootstrap/react-bootstrap 3. https://github.com/esbullington/react-d3

In Marty.js – A JavaScript library for state management in React applications