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.

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

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

But… it doesn't? 0.14 just provides a simpler way to define stateless components. For a component user, there should be no difference between a "functional" stateless component and am "object" stateless component which defines a whole class with only a render method.

I might not understand your point, but the user of the component shouldn't have any need to know whether it's stateful. A stateless `Photo` function component should have the same interface as a `Photo` class component: `<Photo ... />`.

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

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

(How's that different from just a function? It shows up as separate thing in React DevTools, it can have default props or, in the future, shouldComponentUpdate (or built-in memoization strategy?), you can potentially later change it to be stateful without rewriting consuming code, etc)

In the past I've had to keep a handle on the DOM nodes for ad slots that may hide/reshow when a window was re-sized, so the same ad was kept.

However, this should be the exception to the rule, and I still love the React way over components (Polymer) or angular directives.

Another option is to use psuedo-local state with Redux and pass everything as props: https://github.com/rackt/redux/issues/159. As Dan notes in that issue though, it might be better to wait for the state tree model to be improved: https://github.com/facebook/react/issues/4595.

In short: early days, too early to tell what patterns will emerge.