React: Another Level of Indirection

http://www.lispcast.com/react-another-level-of-indirection

by mercer • 13 years ago

213 82 13 years ago

daemonk• 13 years ago

I wonder if it's possible for browsers to start implementing this natively.

Have the browser make a shallow copy of the DOM and allow developers to manipulate the shallow copy. Then have a update() function that will take care finding the diffs and update the actual DOM. Seems like it would be much faster than a javascript implementation also.

drcode3• 13 years ago

Yes, this I'm hoping this will happen over the next few years... this is how us web developers are going to escape DOM manipulation hell.

girvo• 13 years ago

At that pint you have now implemented a desktop UI styled API 'n the browser! I'm not against that by any means, I just think it's funny :)

jt21903• 13 years ago

This is exactly the goal. The DOM's strength was representing documents, not user interfaces. In this era of web apps, trying to use the DOM to build UIs is a massive pain. The web is really years behind in providing a native UI tool kit, and all of this DOM abstraction is just an attempt to paper over the real problem: The DOM is not good for building UIs.

clarkevans• 13 years ago

I've been playing with Facebook's React to make an internal interactive resource scheduling system for our company. So far I think I'm getting it... and am thrilled with how it works.

React eschews the attempt to split the View / ModelView that are the hallmark of most full-service frameworks. Instead of this separation, React applications are built by defining reusable, nested components, each having a render() method that mixes binding and logic to build sub-parts of a web page using their custom DOM. Each component has an internal mutable state and a set of read-only properties it gets from its parent context. In React, "data binding" is just part of rendering.

Since React owns the DOM, it's incompatible with JQuery; or rather, if you use JQuery, you could do it in a leaf node and manage the boundary carefully. React tracks things by using a hierarchical identifier, each key unique within each level of the structure. It then has a predictable/fast algorithem for detecting changes and updating the DOM. Unless you provide your own component keys (used to build the DOM id) all the way down, you need to use CSS classes (rather than IDs).

Finally, I'd say, React really seems like a library -- and one that has a low API to functionality ratio. That is, it really does something substantial with relatively few things you need to learn. If you have your own in-house framework, it might be something you could weave in gradually rather than do a wholesale adoption of a larger (measured via API surface) framework.

Pacabel• 13 years ago

I haven't used React, but the approach you describe sounds very much like how early C++ UI toolkits worked. Applications would be built of "reusable, nested components", often called "widgets". The widgets would be placed into a hierarchy, with widgets often creating their ancestors. Widgets would have a paint() method that would take the widget's internal state and the state of the widget's container(s) into account when displaying (or updating a previous display) of the widget.

- Pacabel

pygy_• 13 years ago

Just to let you know: the guidelines ask not to sign your (otherwise perfectly good) comments.

http://ycombinator.com/newsguidelines.html

wavefunction• 13 years ago

One thing I'm not clear from your description is... The widgets were tightly-coupled with their ancestors? (In order to create them)

drcode3• 13 years ago

You're only seeing one small similarity- React components are very different from old-school components.

netghost• 13 years ago

React not playing well with JQuery or others seems like it makes React something of an all or nothing proposition.

Otherwise, it seems like an interesting approach.

spicyj7• 13 years ago

This is false. Although it's true that React makes the most sense when each individual component is all React, it's easy to embed small React components into a non-React application, and you can also wrap small jQuery plugins (like select2, for instance) in React without too much work.

At Khan Academy we've decided to move to React for new JS development but we've had a lot of success moving to it incrementally and building new pieces in React without having to touch the old ones.

polskibus• 13 years ago

You can have jQuery above react - to trigger state change in react's component tree (and DOM rerender). In the same way you can call out jQuery functions that would affect DOM that's not controlled by React. For manipulating the react-controlled DOM it does not make much sense to use jQuery anyway because react's mechanism are better and come with welcome side-effects (like rerendering to browser DOM only when it is necessary).

andrewflnr• 13 years ago

You (and others) say that React can be introduced gradually, but then you say that it owns the DOM and is incompatible with JQuery unless you're careful. How are these reconciled? Can React manage only a subtree of the DOM and let JQ (et al) handle the rest?

spicyj7• 13 years ago

Yes. See my response here: https://news.ycombinator.com/item?id=6995262.

kd5bjo• 13 years ago

Yes; you mount your top-level React component into a <div>, and React won't touch the DOM outside of that.

It also provides hooks that get called throughout the lifecycle of each component, including whenever it's been added to or about to be removed from the DOM. These can be used to integrate non-React Javascript behaviors that want direct access to the DOM, but you still have to properly handle cleaning up when React wants to take your DOM node away.

fforw3• 13 years ago

There's quite a functional overlap between many uses of jQuery and what React does.

Ignoring animations and ajax, the core functionality of jQuery orients itself to the concept of progressive enhancement (http://en.wikipedia.org/wiki/Progressive_enhancement), you have a basic functionality of a page in HTML and you enhance that with scripts for better user experience. Hence most of jQuery methods follow the operations required for progressive enhancement: finding DOM stuff and changing it, registering events etc.

This is what in the end conflicts with the design of React. React is (again ignoring server-side-js prerendering) an all-or-nothing approach. The whole dynamic part of the DOM is constructed out of the virtual DOM. There is no no need to find DOM elements, because the React way would just relink your component to the real DOM result of its previous rendering or you find DOM elements of child components via React refs. To follow React design, you only change the real DOM directly if you need to step outside of React to e.g. integrate another library. The normal modus operandi is to just render new new virtual DOM based on your props / state.

You can do some meaningful things with combination of React and jQuery, e.g. just use jQuery's focusin/focusout to make up for the lack of bubbling focus support in React. Mostly though you shouldn't need to -- by design.

spicyj7• 13 years ago

just use jQuery's focusin/focusout to make up for the lack of bubbling focus support in React

I believe the focus event bubbles just fine in React. If not, please file a bug.

Pxtl2• 13 years ago

...that reminds me an awful lot of ASP.net web-forms. Which isn't a terrible thing... MS had some good ideas with that bizarre framework, it was marred by brittleness, leaky abstractions, and the technology of the day.

dan152• 13 years ago

ASP.NET Web Forms may have been fine if it was only UI and UI logic rather than an odd mashup of UI + business logic + a crazily complicated page life cycle. The initial versions of ASP.NET MVC used Web Forms purely as a view layer which worked quite well.

At my previous workplace we were converting a classic ASP + ASP.NET Web Forms app to MVC. I really love MVC but I did like the component encapsulation in web forms.

ams61102• 13 years ago

I have to say that I have gained a certain technical respect for Facebook after reading about React. I don't and have never used Facebook the webapp, so I really never developed interest in their technical stack (I vaguely knew it was originally PHP and they had done some work with HipHop etc.). But this seems like the first thing I've seen in a long time, maybe ever, that could actually make writing webapps pleasurable in the way that functional programming is.

mtrimpe2• 13 years ago

You should also take a look at Javelin then. It's still more of a proof of concept, but if you love functional programming then it (seems promising to be) even more fun than React for building web apps.

xixixao• 13 years ago

For a quick try of React in CoffeeScript, I put together https://github.com/xixixao/mimosa-hyper

bsaul2• 13 years ago

I've tried to understand what´s so special with react from the project's home examples, but it seems to me like an api similar to angularjs's directives, only using javascript to build the widget´s html instead of a template. Could anyone here with an experience of the two enlighten me?

Edit : to be more precise, i've written fairly complex directives in angular and i don't understand the problem react is better solving. Synchronisation between dom and model is something you have to deal with manually anyway since it often includes validations rules and default behaviors, that can't be guessed easily ( invalid user input, no value appearance, etc..)

spicyj7• 13 years ago

Does this post answer any of your questions?

http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu...

Declarative syntaxes are easier to work with because you can look at your template and see exactly what the UI will look like. Since you're not doing the DOM manipulation yourself, it's completely airtight and you don't need to worry about writing custom DOM manipulation code for each individual part of the UI that can change. Of course, in any framework you can rerender the entire DOM by setting innerHTML on the top level but that tends to be slow and you need to watch out about resetting scroll position, input focus (and value), etc. React takes care of all of this for you.

(You're right that invalid user input is something you need to deal with regardless, but you should need to deal with that only when making forms, never when displaying data that you already have (which is the common case). As for fallback values, it's easy to write something like

  <div>{this.props.author || "(anonymous)"}</div>

in React when building a view.)

adamnemecek• 13 years ago

There was a quora thread where they did some superficial comparison

http://www.quora.com/Pete-Hunt/Posts/Facebooks-React-vs-Angu...

grayrest4• 13 years ago

If you're already using directives to get all your app's state out of the DOM then there's not a lot of practical benefit to using React over Angular. You get some perf gains due to the DOM update batching and it's conceptually cleaner. I think Angular is better for a mixed designer/developer team if the dev builds directives with the goal of letting the designer work independently since non-directive Angular is extremely easy to learn.

The excitement here is that React is a MUCH better match for Clojurescript. The React model is a one way rendering into a virtual DOM, computing a minimal edit list against the real DOM, and applying it in one batch. The idempotent render lines up with pure functions. The batch nature lines up with the epochal time model of Clojure's vars. Clojure's persistent data structures allow react to bypass model mutation checks.

I discussed the topic of client side state with various people at a couple NYC Clojure meetups in the spring and at Clojure/West and everybody had ideas for a solution but nobody had THE solution. The React model, if not React itself, is that solution for Clojurescript. I'm disappointed that I didn't look into the implementation details of React when I checked it out this Summer and found it unremarkable.

bsaul2• 13 years ago

Not sure i got this right, but my client side state lies in the model javascript layer (i'm talking single page application here), and the synchro between model and DOM is handled both by two-ways data binding (not exclusive to angular) and directives for micro DOM states. I don't quite see the need for diffing at the DOM layer, if you can already observe the changes on the model layer and recreate the Part of the DOM...

So maybe it´s just a clojurescript thing, but i really feel like i'm missing something.

juliangamble• 13 years ago

There is a really interesting link between React and Clojurescript in the Om library. There is a great blog entry about Clojurescript and OM by David Nolen "The Future of Javascript MVCs".

http://swannodette.github.io/2013/12/17/the-future-of-javasc...

The claim by David is that, "ClojureScript om based TodoMVC looks 30-40X faster than Backbone.js TodoMVC, which means other JS frameworks left completely in the dust".

https://twitter.com/swannodette/status/412033352699744256

There is some more discussion of Clojurescript and Om on Fredrik Dyrkell's blog on "A slice of React, Clojurescript and Om". The big idea with Om is to simplify idiomatic state management with Clojurescript’s immutable datastructures, while still getting all the performance. He has some nice comparisons with JavaScript and ClojureScript side by side.

http://www.lexicallyscoped.com/2013/12/25/slice-of-reactjs-a...

On Eric Normand's blog post "React: Another Level of Indirection" he talks about how there are four pieces of the puzzle in ClojureScript Web Development - and Om is the final missing piece: Problem: Global state management Solution: Atoms and persistent data structures

Problem: Client-server communication Solution: EDN (also solved pretty well by JSON)

Problem: Callback hell Solution: core.async

Problem: Stateful DOM Solution: React

http://www.lispcast.com/react-another-level-of-indirection

Form your own opinion of course, but these are some interesting claims.

craigching• 13 years ago

In David Nolen's blog post on Om, he has a link to an Om version of TodoMVC. Does anyone see it at TodoMVC? I can't seem to find it.

EDIT: Of course I find it just after I posted this! The link looks like a single link but it's actually two! :p

feifan• 13 years ago

I got started with React on a project last week. It's magic when it works, but initially it takes some thinking to figure out how all the components should fit together, and where the interactions should take place. It took me a while to figure out that my interactions on one component might trigger a method that should belong on a parent component a few levels up, and to have to pass that method down in the props for the child to call.

React provides a syntax called JSX that looks a lot like regular HTML, but is transformed into native JS before it hits the React engine. It's brilliant, but requires node somewhere along the line to do the transformation. I got stung by this — building a Rails app, and Rails on Heroku ships with an ancient version of Node that causes the transformer to error out. Solution in the works (https://github.com/heroku/heroku-buildpack-ruby/pull/177), but if you're using Rails and Heroku, stay away from JSX for now

acjohnson55• 13 years ago

In a Backbone project I'm working on, every app component and view passes a context object down to any children it creates, which is a copy of the context object it received upon creation, optionally augmented with methods it contributes from itself and other providers. So it's basically a component tree, with an API that grows as you descend down the branches (yet remains distinct between branches). In essence, the context forms a sort of scope that subcomponents can use to communicate with others.

By convention, components "import" API calls into themselves in their constructors. This makes it very clear what the dependencies are.

The beauty of this setup is that intermediary objects don't have to worry about explicitly mediating the interface between their ancestors and descendants. The only components that have to do any mediation are common ancestors of components that need to communicate across branches, but this mediation can be contained, rather than polluting the entire hierarchy.

It's also trivial to mock out the context methods during testing. Similarly, you can use a sort of name-based polymorphism to provide alternate implementations of the context methods, dependent on configuration or parent component, perhaps.

It seems to me that a similar scheme would fit nicely with React's model.

ttty2• 13 years ago

After 1-2 hour of playing I've converted my jquery view (still not 100% same, but almost) to a react, look here. There is a mini tutorial too. https://gist.github.com/totty90/8209324

filipncs• 13 years ago

That definitely belongs in an external gist or something similar. I'm surprised hacker news doesn't have a max length.

ttty2• 13 years ago

fixed, sorry

jules2• 13 years ago

Am I the only one who doesn't like React? It is an ad hoc hacky solution to the view update problem. Diffing DOM trees is not just done for efficiency, but also for correctness. If you have a textbox somewhere with the cursor in it, and you update some other part of the DOM because of a network event, you want to retain that cursor position. If you just blindly put a whole new DOM on the page then the user would be confused because the focus on the textbox and the cursor position would be lost. With DOM diffing you have to keep in mind how exactly the diffing is performed because it will have actual visible effects on the user interface when user interface elements have state that is not represented in the model. You just have to hope that Reacts diffing gives you the behavior that you want. And what about interface elements that have internal state but which are implemented in Javascript rather than in the browser itself? React doesn't do anything to solve the view update problem for them. Seems to me that we need a more principled solution that tackles the problem head on, instead of a hack that happens to do the right thing most of the time.

spicyj7• 13 years ago

React's diff algorithm is completely deterministic. For form inputs and other components which have their own state, it's recommended to put a `key` attribute on each one so that React understands what you meant if you reorder elements in a list: http://facebook.github.io/react/docs/multiple-components.htm.... Idiomatic React code usually has very little state except at the top of the tree so this is rarely a problem.

jules2• 13 years ago

Right, but why do diffing in the first place? First generating a whole new tree and then computing the diff is (1) wasteful (2) leads to problems because you need to find the correspondence between nodes to preserve state. If you do something like Self-Adjusting Computation [1], you can still write your program as if you are generating the DOM as a function of your data, but the machinery under the hood can compute the diffs directly by keeping track of the dependency graph and the correspondence between the old and the new is fully automatic.

[1] http://www.umut-acar.org/self-adjusting-computation

Assume you have a function f that takes the model data as input and computes the DOM as output:

    dom = f(model)

If we now do an update to some model data, that has some effect on the DOM. When executing f for the first time, the machinery of self-adjusting computation records the dependencies of the different dom elements on data in the model. If some part of the model is updated it can propagate the changes along those dependencies to compute the parts of the dom that change as a result.

swannodette• 13 years ago

React components can have local state and setting local state triggers subtree re-renderng.

driverdan• 13 years ago

It sounds like you've never tried using React. It has built in solutions for the issues you mentioned.

__--__2• 13 years ago

Could you elaborate on that, please?

jkroso• 13 years ago

there is no reason react can't automatically store state like focus and cursor position for you

jchrisa2• 13 years ago

I spent the holidays building a four screen admin UI with lots of fast moving tables and lists, and React was able to work with me from who-cares spaghetti all the way to clean enough to hand-off to a team, all without missing a beat or imposing much up-front cost. I'm a fan now.

porker2• 13 years ago

As someone who spends his entire life writing admin screens and more user-friendly but complicated to develop variants of CRUD, I don't suppose you could release the source code of what you wrote?

jchrisa2• 13 years ago

Always do. I plan to debase this before merging to master (the history is a mess) but here it is

https://github.com/couchbase/sync_gateway/tree/adminUI/utils...

(Edit to link to my jsx views.) Also I only barely used the forms stuff so I haven't got an opinion on it yet.

ChristianMarks• 13 years ago

My takeaway:

Any other problems left? I can't think of any. That's something to discuss on Twitter.

Meaning that the remaining problems are trivial misconceptions that can be disposed of within 140 characters.

Edmond2• 13 years ago

Like this a lot! especially the live update example on the website. I think we are beginning to see how web developer tools that are browser-based make certain things possible that would never be possible with native tools.

dkersten2• 13 years ago

how web developer tools that are browser-based make certain things possible that would never be possible with native tools

What do you mean? Can you give me an example?

Edmond2• 13 years ago

Yes there are many...for instance visual layout driven web development is one obvious example.

I know people who prefer native tools always get defensive about the idea of the browser becoming the default platform for web development (and possibly software development in general), but I really don't see it happening any other way.

The ways browser tools for instance can use the browser itself to help simplify web development is something native tools are never going to be able to do. For instance I envision being able to integrate the debugging/developer facilities built into the browser directly into my browser-based developer product without much heavy lifting.

I may be bias given that I am a founder of a startup (see profile for link) building a browser-based developer product...but I have also spent years working with native IDEs including attempting to build my own IDE (http://bit.ly/IwZCEL), the browser advantage is just apparent to me. Granted there are still improvements to be made to browsers in order to bring them to parity with native environments for software development in general but I think it is just a matter of time.

chenglou3• 13 years ago

React user here. Some comments seem to suggest that React doesn't play well with other libraries; it's really the opposite. Here's a React Chosen component in 25 lines of code: https://github.com/chenglou/react-chosen/blob/master/react-c...

The React todomvc examples also uses Backbone and/or Director.

jgalt212• 13 years ago

ReclineJS is pretty awesome, albeit a bit slow, with larger data sets. I'd wonder how snappy it would be if it were ported over to react.

http://okfnlabs.org/recline/

joesb• 13 years ago

It would be great if someone can extract the virtual DOM engine part into its own library. New framework/library with different approach in other area can be develop while utilizing the virtual DOM part.

At least I would love to see the combination of Angular directive (ability to combine cross-cutting aspect into a single DOM node and, may be, digest loop) with React's virtual DOM.

React: Another Level of Indirection

Related Stories