This stuff is the real deal. I've been using it for ~6 months now and can't imagine now building websites without it. For Coffeescript fans, I use this to start off all new apps — https://github.com/KyleAMathews/coffee-react-quickstart
Indeed, this is simpler in ClojureScript world where all state is kept in a single place. It's harder to do the same for JavaScript React components that may have local state, but as you see, it's perfectly possible.
Also, as far as I'm aware, ClojureScript hot reloading tools actually unmount the component. This may be OK because state is restored from one source, but it's not as nice-looking because DOM is thrown away on every update, and it flickers.
What? When's the last time you've used Chestnut? Do you have an example I could look at? I ask because it sounds like you're doing something that re-renders the entire application instead of the components that need to update.
I may be wrong but I don't think Chestnut will patch existing instances? And without patching, I imagine React will recognize new version as a different type and bail out of reconciliation. I didn't try it, just chatted with David on Twitter and that's what I thought. Maybe I got it wrong!
Anyway, I'm looking forward to learning more about ClojureScript. A lot of exciting things coming from there.
Interesting - I've just started playing around with jspm and system.js as showcased in the "Javascript in 2015" video that did the rounds (http://glenmaddern.com/articles/javascript-in-2015) and I'm wondering if there is a way to achieve something similar with that tooling? Can webpack be used alongside jspm and system.js or do I need to change the way files are required?
Hi, I don't think it's possible with System.js. Nevertheless I decoupled internal implementation from Webpack so it can be used in future hot-reload-capable build systems:
The distinction between the back-end and front-end is a product of the complexity introduced by the web with its 'worse is better' mix of badly integrated tools. It made building user interfaces a dark art with all its quirks:
- a layouting system that had an active vendetta against humans
- Javascript with all its deficiencies
- Connascence introduced by Server <-> Client communication (Server Model <-> API View <-> JS Model <-> JS View)
- declarative views that were ill-suited for web-apps (logic-less templates, what a lie!)
- cross-browser incompatibilities
- difficulty in implementing client-side routing
- immature developer tooling
But worst of them all was DOM mutation and spaghetti code, which was in reality a fundamental deficiency of the development model itself, and not because web developers the world over were being deliberately irresponsible.
React is changing all that with the help of ES6. It simplifies web development both in concept and in practice. In a few years, building UIs would be just another part of writing software, and competent Full-Stack developers would cease to remain unicorns.
Here are a few things that React approaches differently that makes all the difference:
- the basic unit of a front-end system is a 'component'. A component knows how it is rendered (HTML), how it is styled (CSS), how it behaves (JS), and has explicit knowledge of the data it handles (states and props).
The React team seems to be looking at what makes web development actually hard and are thinking outside ill-advised conventional wisdom (like separation of concerns. whose concerns anyway?). For example, Relay (https://gist.github.com/wincent/598fa75e22bdfa44cf47?), removes the need for writing custom API end-points for each of our components. A component already knows the data it needs, but today we leak that info across the component hierarchy and to the server, creating a lot of accidental complexity.
Another example is Webpack (http://webpack.github.io/), which changes asset management on the web by making it completely programmable. All your static assets should have the same bundling conveniences that your JS has. Webpack also makes react-hot-loader possible with Hot Module Replacement.
React seems to have finally figured out the right direction to take the web to. Exciting times.
I think you forgot something that is very important to React: your component is a pure function that takes props and states and that outputs UI. Being able to make the assumption that given the same props and state, you'll get the exact same UI (to the cursor position), is extremely powerful. As a programmer your brain can focus on other things and forget about side nasty effects.
In React your component is a class. The `render` function is a pure function, but the component itself is a state machine. This is why I prefer Mercury[1]
True. No more spaghetti ball-of-mud. I'm waiting for IntelliJ to release `Extract custom render method` and `Extract React Component` refactors in their IDEs.
> A component knows how it is rendered (HTML), how it is styled (CSS), how it behaves (JS), and has explicit knowledge of the data it handles (states and props).
I don't get this. Sure, components seem sound but often a component is dependent on its context. So a component in the header may need different margins for example than one in the footer. How is this handled in React where the components seem really isolated?
This question has more to do with how we think about abstractions than React itself.
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.
The same exact problem exists inherently in CSS itself and has been addressed in many ways through different kinds of conventions.
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.
React isn't against templates - the existence of JSX is counter to this. React does choose to consume templates in an imperative form (via React.DOM), and JSX is meant to ease this flaw in productivity by giving tooling that corrects this unnatural form of development (for most frontend engineers).
React is also not against separation of concerns - even in the talk by Pete Hunt linked, he merely has a different view on what constitutes the concern of the view layer. His viewpoint is that the template and the state of the component are intertwined heavily, so as to stress that Facebook's approach with React does not break that principle.
Thanks for your thoughts. I should clarify what I meant by templates.
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.
I like a lot of what I see with react except the lack of 2 way data binding. Mainly, I tend to have input data tables for forecasting, cost estimation, and so forth with a lot of data inter-dependencies and calculations. 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.
Nope. Lack of two-way binding is a blessing. It makes everything predictable.
>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.
I'm not sold two-way binding tools get inherently complicated, I just haven't seen this increase in complexity in our current app which is quite large. But I am attracted to react for the reasons you mention, the virtual DOM aspect is very nice so I'll give this a shot.
Although even though ReactLink works it a.) feels like quite the hack (i.e. not very composable) and b.) is a more code to maintain still when it comes down to it.
If something can't be described very simply, it scares me away. There are a lot of decent individual ideas and concepts in this gist but from an overall perspective it is very concept-stage stuff which leads me to believe it is a lot farther from a well honed proposal then we are being lead to believe.
If they deliver something concrete and simple it could be great. But there are way too many questions at this point to even start to get excited.
Allow me to be the detractor to all the fanfare - what does this actually do? The demo site hints at what is going with it's tutorial but I don't see in plain english. It seems, if I follow the tutorial, that as I modify the includes in the editor the javascript assets are reloaded in real time to reflect the state of loaded javascript.
So, I guess I'm looking for a technical summary of what this does exactly because I don't understand the benefit.
It's instant feedback. You should try making an app with animations. You leave the animation looping and you modify your constants and you don't have to reload or do anything, ReactHotLoader will plug in your new code without losing the state of the app.
You get much faster prototyping, collaborative tools out of the box and even a debugger with a timeline out of the box (you just have to save your state at every change and have a little scrollbar to scroll through your states). This is very very powerful.
The main benefit for a developer, as far as I can tell, is that the state of the app is maintained between reloads. So you can interact with it — e.g., type into an input, make selections in dropdowns — then change the code behind it and everything you did will still be there.
The site does say:
> React Hot Loader will keep it mounted, preserving the state.
but I agree that it could be more explicit about how it's useful.
Yes, not losing state is a big deal. This is possible because the UI is stateless while React is a view on that state. We built a similar system (for TouchDevelop) in a PLDI paper a few years back:
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.
Basically if you save the code behind the component (even if your text editor), the components will reflect the new code without a page refresh. It's for development, it seems.
This is correct. Not just without refresh, but without throwing away the DOM—we'll just re-run React's algorithm.
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).
Gadzhi (you may know him as the designer behind Sublime Spacegray theme, http://kkga.me/) helped polish the logo and added the outer animation. It's currently in CSS but I plan to to move it into the component as well.
