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.
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
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.
> 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 ... />`.
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>;
}
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.
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.
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).
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.
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.