Show HN: React 0.12 renders to Web Components

Show HN: React 0.12 renders to Web Components(gist.github.com)

45 points by OlavHN 11 years ago | 10 comments

rictic 11 years ago |

This seems cool, but I'm a bit confused (background: I've been working with web components and polymer for the past couple of months, but have only read a couple articles on React, apologies if this is a dumb question).

This says that react renders to web components, but it looks to me like react is just adding a web component to the area of the DOM that it's controlling. Is more going on here? e.g. doing the same thing with jquery:

    $('<core-icon>').attr('src', "//www.polymer-project.org/images/icons/android.svg").appendTo('#jquery-root');

Is the idea that React is doing data binding to the src attribute?

OlavHN 11 years ago | |

Before it was hard coded what HTML elements react would represent in its virtual DOM. With 0.12 thats no longer the case, so it can now also render to custom elements. So now it might be possible to define fancy UI elements in web components and then keep state and structure with React.

Bahamut 11 years ago |

How would data syncing work between React and the components seem to be a more important question. One doesn't really need React to create a web component in this example.

bwhitty 11 years ago |

Polymer uses standard 2-way data binding. How does this fit into React's flow? I'd love to see an implementation of Polymer using the Flux architecture.

andrewingram 11 years ago | |

From using the Flux architecture on fairly big projects, we generally follow the rule that any re-usable component (such as a datepicker, custom select box, modal etc) can internally do whatever they want with regards to state and data binding. These components interact with their parents using callbacks, it's these callbacks that interact with Flux. This feels fairly compatible with Web Components.

For example, say you have a custom select box. You don't want to fire a flux action when a user clicks on an option. You want that click to be handled by your select component, and be interpreted as an intent to change the value. Your select component then triggers its onChange (or onSelect, doesn't really matter) callback if it has one. The parent of the select component is then responsible for saying "actually the rest of the page should know about this value change, i'll trigger a flux action".

The end result is that your reusable widgets/components have no knowledge of flux, but the implementation of a particular page or piece of functionality does.

OlavHN 11 years ago | |

I started on a project to port the paper elements from material design to react components (https://github.com/OlavHN/react-paper), but the paper elements I ported all seemed really stateless. More like high level input elements. Now I'm hoping that they can be used directly by mapping custom element attributes to react props or maybe they would work with a small wrapper. Needs more experimentation ..

miralabs 11 years ago |

I don't get the advantage of this. What is the diff with $("<core-icon>")... call?

werdnapk 11 years ago |

Why does the icon src need to be specified twice?

bsimpson 11 years ago | |

It isn't. There are two icons on the page (to show they are identical). Look in Web Inspector - only one is in #react-root.

IDK why the OP decided to name the variable `div`. It'd have been much clearer if it was named something like `reactIcon`.

OlavHN 11 years ago | | |

Oops