News for hackers. Stuff that matters.
Re:React v0.14 by devit on Wednesday October 07, 2015 @02:17PM (#10347835)
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

Re:React v0.14 by lobster_johnson on Wednesday October 07, 2015 @02:28PM (#10347921)
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.
Re:React v0.14 by masklinn on Wednesday October 07, 2015 @02:44PM (#10348038)
> 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.

Re:React v0.14 by clessg on Wednesday October 07, 2015 @02:28PM (#10347917)
> 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 ... />`.