React early days - Flux, react-cursor braindump

HN: Why We Use Om, and Why We’re Excited for Om Next (Jan 2016)

Application state as a single, immutable data structure.
react-cursor gives this pattern in javascript, immutability and all, but with regular old javascript objects. It also comes with all the same caveats as in this article. (I don't speak for the creator of Om, I speak for myself as the author of this library which was inspired by Om and Clojure)
The beautiy of the state-at-root pattern with cursors, is that each little component, each subtree of the view, can stand alone as its own little stateful app, and they naturally nest/compose recursively into larger apps. This fiddle is meant to demonstrate this: https://jsfiddle.net/dustingetz/n9kfc17x/
The tree is really a graph.
Solving this impedance mismatch is the main UI research problem of 2015/2016. Om Next, GraphQL, Falcor etc. It's still a research problem, IMO. The solution will also solve the object/relational impedance mismatch, i think, which is a highly related problem, maybe the same problem.
Solving this impedance mismatch
The solution seems now to get rid of the REST paradigm(GraphQL ...).
While I have no opinion on what should be the right solution, I welcome the idea of questioning the usefulness and the significance of REST, especially in the era of fat web clients.
  • aikah | on: Why We Use Om, and Why We’re Excited for Om Next
My opinion is that REST is exposing the O/R impedance mismatch to the client, and we are only feeling this now as our client apps get really complicated, and i think the O/R imnpedance mismatch is caused by pervasive mutability, and i think the problem can be solved by making the database immutable (e.g. CQRS/ES, Datomic), and i think that will make the problems with REST go away too. (This is not quite what GraphQL is trying to do, GraphQL is progress but doesn't get to the crux of it) This is all research of course, and completely my opinion. Om Next is meant to be paired with Datomic so while his solution is to throw away everything that is even a little bit RESTy, i think that might be throwing the baby out with the bathwater. time will tell.

HN: Immutable Data Structures and JavaScript (jlongster.com) (Oct 2015)

Where does React's Immutability Helpers fall in this spectrum? I was mulling over switching my entire codebase to ImmutableJS when a friend asked to try them first. It worked out well, but I wonder whether anyone here has experience with it in a large long-running project. So far it has allowed me to use Javascript primitives everywhere; all I need to ensure is to avoid direct mutation and use update that gives a new object whose properties shares the same references with the original one, except for the path in which the leaf node that needs to be mutated sits.
  • jasim | on: Immutable Data Structures and JavaScript
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: image We had all sorts of complexity scaling problems while building this, but none of them were due to state management, migrating to cursors made 99% of pain due to complicated ui state go away.

HN: GraphQL/Relay Wins. Flux/Redux Considered Harmful (Feb 2016)

"Flux considered harmful" That is way too strong - GraphQL handles server/client data sync, we still need a pattern for client/ui state, they are mostly orthogonal concerns. UIs aren't stateless, there's more to it than just transacting every state change directly to the server. It is a very narrow class of UIs for which that could work.
UIs aren't stateless i would agree that this is the traditional perspective.
i'm not convinced this is necessarily the case; there may be other ways to look at it. it could be that the ui "value" is the output of a series of functions, and that what might look like a "state" change is really a "new" ui being rendered.
(maybe this is what "frp" gives us, or perhaps "immediate mode gui" that sometimes pops up in game development circles; but i'm not very familiar with either.)
  • hnbroseph
It is always the case. Even if you model app state in a functional way, the state is still somewhere, for example a haskell program may be pure but only because it pushed the unsafePerformIO call into the runtime. UIs always have additonal state that is not modeled in the backend, we can only reduce the surface area of code that is stateful, but we can't outright remove it, it is essential complexity in all UIs.

HN: Pros and Cons of using immutability with React.js (August 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, which is basically sugar over the React immutability helpers 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

HN: React-cursor: a JavaScript implementation of the Cursor concept first seen in Om (September 2014)

HN: From Backbone to React: Our Experience Scaling a Web Application (September 2014)

I've still yet to figure out how to easily update nested datastructures with this immutable stuff.
Say we have a try of data, Rows -> Row{name, id}
Say we have a component,
On the Row, component, we want to update our "own" name, so with mutable stuff, (ignoring state updates), we could set this.props.name = "potato".
Say the structure of rows was managed by a statemanager, then how do we get that to do it?
Does rows do something like this.props.updateRowName(this.props.row.id, newName), then the statemanager "queries" the rows and somehow replaces the entire dataset tree with a new one where that specific row's name has been changed?
Really fascinated to know, as I'd love to move to this model.
Om seems lovely, but I'm not comfortable enough with Clojure(script) to move to it, let alone force it upon others in a team.
  • antihero
you are right, this is a sticky spot when using immutability from javascript
  • you can clone-and-mutate (I started here, but it quickly became a bottleneck in my app, and jr developers forget a lot leading to hard to find bugs)
  • you can use real persistent datastructures (Mori), but now you have added a cross cutting concern - which type of array is the one i'm working with right now?
  • you can use React.addons.update (I use this successfully, but you need to get used to a weird syntax) Om provides an abstraction over React state called Cursors which provides immutable updates to react state at any point in a state subtree. I ported this concept to javascript (implemented in terms of React.addons.update) and have used this successfully in two large scale enterprise applications for regulated industries and I know of one other company using this. This provides a very clean and elegant programming model for immutable updates to react state.
Todo