Comment by clessg | Hacker News Reader

Comment by clessg | Hacker News Reader

A lot of great ideas in this release and it makes me excited for the future of React.

I've been on 0.14-rc1 and my favorite feature so far is stateless function components. So much cleaner than class-based components.

One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.)

Andrew Clark (core contributor to Redux and creator of Flummox) just released Recompose which provides powerful capabilities for stateless components: https://github.com/acdlite/recompose.

Some of the benefits of stateless function components as outlined in Recompose's readme:

* They prevent abuse of the setState() API, favoring props instead.

* They're simpler, and therefore less error-prone.

* They encourage the smart vs. dumb component pattern.

* They encourage code that is more reusable and modular.

* They discourage giant, complicated components that do too many things.

* In the future, they will allow React to make performance optimizations by avoiding unnecessary checks and memory allocations.

>One downside is that hot reloading doesn't work with it yet (AFAIK). Hopefully that will come soon now that 0.14 is officially released. (And I believe Dan is/was on vacation.)

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.

Note that the stateless part is mostly just a stepping stone to a stateful variant.

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

Yep, I saw that, and that's even more exciting. Any possibility of 0.15 or 0.16 on that front?

The idea of giving special consideration to "stateless" UI components in this sense seems ill-conceived, because adding or removing UI-related state should not have any extra implications.

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

> The idea of having "stateless" UI components in this sense seems ill-conceived, because whether a UI component has state should not be a concern of the user of the component.

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 ... />`.

You embed stateless (function-based) components just like you do for normal components. There is no interface difference; the caller doesn't need to know whether the component it is using is stateless or not.

> The idea of giving special consideration to "stateless" UI components in this sense seems ill-conceived, because adding or removing UI-related state should not have any extra implications.

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.

Thanks for the link! Should clarify that Recompose works equally well with stateful components created with either createClass or React.Component. It just happens to be especially useful for stateless functional components :)

What exactly is different? I've been using "stateless function components" with react 0.12 and 0.13. Just write a function that returns a ReactElement, eg:

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

Then use it elsewhere in your code like a normal function:

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

Looks like they've just added first-class support for that pattern, so you get propTypes, defaultProps, etc.

Also in the future this pattern will be faster thanks to React not having to maintain an internal instance for such components.

(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)

I also like stateless function components. If you are using Redux, all the state management can be done at Redux side and you can make all React components stateless. And they become even easier to write after this release.

Is it possible to build an entire app with them using Redux?

That should be possible! Of course, stateless components don't have state, so you would need to something like Recompose if you need that. And of course, not all React-related projects explicitly support stateless components at the moment (e.g. hot reloading).

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.

The Elm and Reagent (Clojurescript) communities build apps this way. It's theoretically possible to do everything in render in practice you wind up wanting to do things in other lifecycle events (e.g. display a google map) in most apps. There isn't any component local state but the components aren't pure render functions either.

In general, interacting with anything that does more interactive rendering (three.js, google maps, ads, etc) requires access to lifecycle events beyond a simple render method...

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.

I generally try to do everything in render(). It almost always works out better. Sometimes I end up needing a lifecycle event. Timers (e.g., for manual animations) end up being hard to model without mount/unmount.

Agreed.. using mount/unmount is the exception to the rule.. I can imagine anything using charting libraries, or any third party rendering library would need to do this for performant controls... but it is definitely the exception to the rule.

So basically, react is becoming like mercury one release at a time.

Reply on news.ycombinator.com