React Hot Loader: Tweak React Components in Real Time

http://facebook.github.io/react/docs/two-way-binding-helpers...

>It seems going back to the method of handling data updates through onchange events in a manual fashion would be a colossal step backwards from say, knockoutjs.

It's not exactly "manual fashion" because React updates everything according to `state` for you. If you have many interdependent fields, make them update `state` correctly, and React will keep them in sync with it.

In fact I find it easier to make complex input logic with one-way bindings because the data always flows one way. It's a tad more code to write, but you see exactly where your updates are happening and what's causing them.

Two-way binding tends to get very complicated as soon as you need more complex logic. One-way binding doesn't have this problem.

https://news.ycombinator.com/item?id=8977229

Templates are driven by content, not by logic, and they are typically monolithic. This works well for web pages which are about content which doesn't have much JS. The web was historically content-driven, which has started changing only recently with the evolution of Javascript and the emergence of web-apps. This historical quirk is why imperative construction of the view is unnatural form for developers. This is however going to change fast, because imperative view construction is the natural way to build web apps.

JSX templates are templates in the sense they do minimal string interpolation. Everything else is taken care of by programming language abstractions. They include control structures: conditionals and loops, and primitives for abstraction: variables, functions and objects. A template 'programming' language on the other hand is a suboptimal mix. For example, Angular's templating language reminds me of Greenspun's 10th rule, which with suitable modifications, can be read like this:

  Any sufficiently complicated templating language contains an ad hoc,
  informally-specified, bug-ridden, slow implementation of a 
  turing complete programming language.

[1]https://github.com/Raynos/mercury

In plain CSS, you can specify a specialized parent -> child rule that affects the component just in this context. Or you can have two different classes for the two cases. You can also define two distinct container elements that compose the same underlying component, but the container takes care of the margin depending on the context.

All of these options work with React as well. However, it lets you go further: you can pass the context info into the component, which then adjusts itself. Or the parent element in both cases can wrap the component inside appropriate html elements, or have specific container components, all using imperative Javascript to construct the view.

With React you have the entire repertoire of programming abstractions to solve this problem with, while traditionally we had to work within the confines of CSS's cascade.

But in cases where internal layout of the component is very different, we have to make a call between adding conditionals within a component vs giving distinct names to the different cases and extracting multiple components. I veer towards having more explicit names in my codebase and so extracts new components more often than I litter existing ones with conditionals.

Also, in practice, components are surprisingly self-contained and independent of context.

One way is to mix two different sets of styles for the element.

Set 1 gives the element the general styles of the component itself.

Set 2 gives the context-specific styles that are only used in that one instance.

It's just like using two different classes. E.g. `.button` and `.firstButtonInHeader`. And then having an element like <button class="button firstButtonInHeader">.

Since components in React are declarative, instead of using a restricted tool such as CSS classes, you have the full power of JavaScript to construct these mixins however you like.

This gives huge productivity boost when developing complex nested UIs because you can quickly tweak CSS/JSX without blowing away all the state (like modal windows, tabs, loaded data, etc).

http://research.microsoft.com/pubs/189242/pldi097-burckhardt...

From the paper, adding a navigability aspect between UI and executing code is something that is fairly straightfoward to do and very useful.

My current live programming work is over stateful code (meaning the code that is being live edited involves side effects). It is difficult to support that in existing programming models, however.