

React's Diff Algorithm - vjeux
http://calendar.perfplanet.com/2013/diff

======
schrijver
I wonder if React’s algorithm could be used to implement support for
‘operational transformations’ on DOM trees?

OT is the technique used for collaborative editing, etherpad-style. Current
implementations don’t work with conventional DOM’s: Etherpad has its own model
of plain text with an additional ’attribute pool’. Libraries like
[http://sharejs.org/](http://sharejs.org/) only know to deal with plain text
and JSON.

I would love if I could implement a collaborative editor that hooks into an
existing HTML element on the page, in the way contentEditable allows for in
single-user apps.

cf
[https://github.com/share/ShareJS/issues/1](https://github.com/share/ShareJS/issues/1)

~~~
amix
For OT to work you would need the ability to track all the changes and mirror
them to the other users. React appears to have the ability to track changes,
but I am unsure how easy it would be to mirror them over the network.

There's a great article here that describes how OT and other synchronization
algorithms work (OT is event passing):
[https://neil.fraser.name/writing/sync/](https://neil.fraser.name/writing/sync/)

~~~
vjeux
React internals support being used in a web worker. It should be easy to send
it via XHR.

Now, synchronizing two clients is going to be more tricky. The diff algorithm
works on the virtual DOM which is the result of an arbitrary javascript
execution.

So while it's certainly possible to synchronize and merge the virtual DOM.
You'll need to also feed this result back to the javascript program that
generates this virtual DOM. The next time you call render, it should return
the new merged virtual DOM.

This would be a pretty exciting thing to be able to do, i'd love to see a demo
:)

------
kenster07
It would seem that browsers could implement the exact same algo using native
code and achieve far better performance.

This raises the question: why aren't browsers already using this or something
superior?

~~~
tel
Probably a big difference in the API applied; the DOM model may be much more
flexible than what React allows.

------
dangoor
I implemented something similar for Brackets so that it could do "live
development" of HTML. In an editor, it's not uncommon to need to reparent a
node, so our algorithm supports that.

I had a chance to speak with some of the React team at JSconf.eu and there are
similarities in our approaches, but it turns out that what you're trying to
ultimately do (an editor vs. an rendering application views) makes a big
difference.

For those curious, here's the talk about what goes on in Brackets:

[http://2013.jsconf.eu/speakers/peter-flynn-kevin-dangoor-
omn...](http://2013.jsconf.eu/speakers/peter-flynn-kevin-dangoor-omniscient-
debuggers.html)

------
pornel
React's rendering looks really awesome, but I'm missing the bit that binds
application data to views.

e.g. in KnockoutJS I can just use observable arrays and properties and never
have to call `setState()` on anything. What's the equivalent for React?

~~~
peterhunt
You can very easily do this by combining Object.observe() (or a polyfill) and
calling forceUpdate().

However we've found that this sort of data binding is suboptimal since it
encourages mutation which forces you out of some great perf optimizations
(like the Om stuff, and Object.observe() has its own performance penalties).
And thinking about your data flow a little more explicitly makes it easy to
follow where updates are being triggered from (so a mutation in one part of
your app doesn't accidentally trigger updates all over the place).

Most of the time doing this explicitly is a little more typing up front but is
worth it for larger apps from a performance and maintenance perspective. If
you start building with React you'll find that your data model flattens out as
you go down the view hierarchy so this becomes less of an issue.

~~~
juliangamble
You can read more about how React combined with immutable data structures
provides great performance in this blog post by David Nolen
[http://swannodette.github.io/2013/12/17/the-future-of-
javasc...](http://swannodette.github.io/2013/12/17/the-future-of-javascript-
mvcs/)

------
enginous
I think the stuff React is doing is impressively simple and non-magical.
Although I haven't used React yet, I wouldn't be surprised if these ideas make
for code that's relatively easy to reuse and reason about.

The format of the post is also quite nice; a few short points with
illustrations and a clear takeaway.

~~~
Touche
I use React and like it a lot. The biggest issue it has right now is there is
no good way for a component on one branch of the tree to get information to a
component in another branch. You have to talk to your parent components by
having them attach a function as a property, and this simply doesn't scale to
large or even medium sized applications.

~~~
peterhunt
This model usually works pretty well for smaller components (see
[http://facebook.github.io/react/blog/2013/11/05/thinking-
in-...](http://facebook.github.io/react/blog/2013/11/05/thinking-in-
react.html))

For larger ones, we provide lifecycle hooks so you can set up these
subscriptions manually. In componentDidMount() and componentWillUnmount() you
can subscribe/unsubscribe to some sort of messaging system, and when you
receive the message call setState(). Usually you only need to do this in a few
places and the regular React dataflow will carry you the rest of the way.

Does that make sense? We should probably write up this technique.

