4 ms·
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
by devit 11y ago
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
- clessg 11y ago> 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 ... />`.
- lobster_johnson 11y agoYou 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.
- masklinn 11y ago> 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.