React v0.14

For example, if you display photos in a table, there is no state, but if you display photos with a carousel, then you have state as the current page, but these two components should otherwise have the same interface and implementation. Also in general the current selection and scroll position is state, albeit stored in the browser, so any UI component can potentially have state, even if it is only stored implicitly in the DOM objects.

What really matters is whether the component holds any state with "semantic" meaning or that needs to be persisted (like a date the user selected in a date picker) or whether all the state is "presentational" (like the month a date picker is showing).

What you should do in React is not hold any "semantic" state in components, unless it's a component that is solely designed for holding and managing such state (e.g. Relay container components, or a root App component).

EDIT: slightly reworded to be clearer and more correct, since having the same API interface regardless of statefulness is implicit in React

https://github.com/reactjs/react-future/tree/master/07%20-%2...

    function renderFoo(props) {
        return <span>{props.foo}</span>;
    }

    function bar(props) {
        return <div>{props.foos.map(renderFoo)}</div>;
    }

There's work in progress on this, and I'll try to release an update to React Transform & friends handling this next week.

Might take longer to retrofit this into React Hot Loader but if there's enough demand I can try doing this too.

I really hope they do what NodeJS/IO did and figure out that it's far away from any "pre-release" state to keep the version number after two 0s.

To teams who are using it in production, did you talk about this? What are arguments for using it despite it not being 1.0?

It's rare that you don't see a bit of software churn through a few breaking versions rapidly while in the early stages of development, many of which happen well after attracting significant public interest and dependence. Semver provides for this already with the major version and for pre-releases with the `-alpha`, `-beta`, `-rc` suffixes, so 0.x in this case seems to provide developers with an out-clause to consider major revisions non-major and put off committing to 1.0 for far too long.

This also seems to be at least partially fuelled by a historical aversion to hitting double-digit major versions, although we owe Chrome a debt of gratitude for demonstrating to us that there's little to fear by doing so. Hopefully this approach continues to catch on.

Would React's users (and the users of many other extremely popular libraries/tools doing the same 0.x dance) have been better served by declaring a 1.0 version much, much earlier in the development process? I think so.

Not if you want to reuse the server-generated markup. You can use it for little pieces in an otherwise static page, but it needs to own rendering of those pieces.

React is perfect for replacing turning your cooked spaghetti into dry pasta. Entropy for the win!

There are many benefits to using React in an existing website: a great developer experience, performance, avoiding jQuery spaghetti, ease-of-use, etc. It might be overkill to use React for just a few components, but if you want to move to React, then you can incrementally implement components using React and then switch over fully.

> Is it only for SPAs?

In my opinion, React is like the declarative jQuery. It works just as well for SPAs as it does for traditional websites.

Here's an example of a web application built with React, Express and Browser Express that defines the same UI components and routes for both the server and the browser:

https://github.com/williamcotton/universal-react

Basically it controls everything about views.

Flux is a common pattern to use with it (and there's a lot of libraries out there for that) but you don't have to by any means.

This is more or less what I've been using it for at work. My general "rule" is that if I've got a form and any other field or set of fields depends on what's happening in another field or set of fields I try wrap both parts up into a React component (with as many subcomponents as necessary). I'm using react-rails[1] and creating custom form builder modules which I include in my main form builder class. The custom form builder methods just call react_component and pass in the form object as a property to the component so I get server-side rendering of the component and the same code gets reused client-side. Obviously it can be used for much more than dynamic forms, but for what I'm currently doing this is all I need.

> React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code.

I've found that > 90% of my front-end bugs around forms involve fields that are somehow linked. Handling that with unstructured jQuery goes from easy to a horrible mess at a nearly exponential rate as the number of interacting parts increases linearly. React makes it really easy to keep track of state and have it flow downwards as properties to subcomponents. Obviously you can go way overboard with it and I wouldn't recommend it for everything, but the ability to use it in just one troublesome spot and nowhere else if that's all you need is really cool. It's the opposite of all-or-nothing. I have a very large application that uses it in about a dozen tricky places like dynamic lists of things. The rest of the application is just plain old server-side rendered HTML.

1. https://github.com/reactjs/react-rails

Imagine your data is in a tree. Go to the very lowest nodes on the tree. You should be able to imagine that rendering these nodes is quite easy. It's just simple data. Now move up a node. Rendering this node is just rendering the data at that level and telling the next level to render. Keep doing that until you get to the very top.

The rendering at every node is now very simple. It is also very easy to write tests for: You just need to make sure that the data in the node has been rendered and that the nodes below are present.

Of course, that's just rendering a static tree. How do we deal with dynamism? In it's simplest form, you don't. Instead, any time you want to change some data in your tree, make a new tree and then render that new tree. This has the advantage that it is very simple. You tree of data is immutable, and so you never have to worry about state changing. At every change you just re-render the entire tree.

Of course, that is costly, so we can be clever and notice that we don't have to re-render the entire tree. We just have to compare the first tree with the second and re-render the highest subtrees that have changed. React does this behind the scenes.

If you are trying to do a kind of hybrid approach of using react for some parts and not for others, this is actually one of the easiest ways to do it. If you want to update your data from the server, you simple make an endpoint for the data at the top of your React tree and every time you change something you make an Ajax call from that top node to get the new data. This will cause the tree to re-render fairly efficiently.

Of course, this doesn't solve all your problems, because often you don't want to get new data from your server, you just want to update data around your tree. In this case, you need to image every node as the top of a subtree. If you want to change the data in the subtree, you simply make a request to the top of the subtree to modify the data in that subtree. This causes the entire subtree to re-render.

So the main flow is that you have a tree of data which you render. Anytime you want to modify the data, you need to make a request up the tree (never sideways and almost never downwards).

These requests can be made in many ways, but the simplest is simply by passing a callback down the tree as a piece of data. You decide which node "owns" a piece of data and then you pass a callback for modifying that data down the tree. Anyone below can potentially call that callback, which will modify the data at the top of the tree and re-render the entire tree.

There are other ways of doing it. Passing a whole whack of callbacks can be tiresome. Flux, for instance, sets up a series of singleton objects that anyone can access. You make a request of the object, it creates a new tree of data and updates the top node of the tree. (Note: Highly simplified explanation to the point of being wrong ;-) ).

Anyway, the point of this is to say that, if you want to write code this way, then you should use React or something like it. If not, you should stay away, because you will make a huge mess.

https://www.npmjs.com/search?q=react%2C+component

https://www.google.com/search?q=site%3Anpmjs.com+react%2C+co...

Say you subscribe to "name change" event, where you have to update your UI depends on your current UI state. Are you in list page? Are you in detail page? Is the object even currently displayed at all?