Docs terminology "smart" and "dumb"

[ryanflorence]

I'd love to change the vocabulary to "stateful" and "stateless".

[erikras]

I agree. The smart/dumb dichotomy never really made much sense to me.

Another option would be "connected" and "unconnected", since "state" could be confused with React component state. A component could have React state and not be connect()ed to the Redux store.

[namelos]

Imo "connected" and "unconnected" would be better, in fact I could write as follow:

const MyComp = ({ myProp, myAction }) => <div>
  <h1>{ myProp }</h1>
  <button onClick={ myAction }>Click Me</button>
</div>

export default connect(
  ({ myReducer }) => ({ myProp: myReducer.myState }),
  dispatch => bindActionCreator({ myAction }, dispatch)
)(MyComp)

It is stateless function component while it was connected to redux, so "stateless" might be kinda confusing.

+1 for "connected" and "unconnected".

[gaearon]

I'm up for changing it but let's choose terms carefully.

[gaearon]

“Stateful” and “stateless” is a different, and not necessarily relevant distinction. A component may be stateful (e.g. holding a local form or “dropdown toggled” state) but not aware of Redux.

[gaearon]

“Connected” and “unconnected” component is closer to the current smart/dumb distinction, but it still has some confusion potential.

const Counter = ({ value, onIncrement }) =>
  <div>{value} <button onClick={onIncrement}>+</button></div>;

export default connect(
  state => state.counter
)(Counter);

Is Counter connected in this example? Seems so. But wait, no, Counter is not connected—it's the component generated by connect() that is connected. We export it so for outside code, Counter export is a connected component, but Counter itself in this source file is not connected per se.

This is why I don't quite like saying “connected”. The argument to connect() is the unconnected component, but the fact that it is passed to connect() makes it natural to assume that is the “connected” component because it is being connected.

[gaearon]

One way out of this mess is to probably stop calling “dumb” component anything special, and call the “smart” components the container components. This is consistent with Flux and Relay documentation and API.

[ghost]

Containers, in my mind at least, just click when it comes to understanding the distinction

[ellbee]

Another vote for container here. As well as being consistent with Relay, the term is also already used in the folder structure of the Redux examples.

[gaearon]

Khan Academy calls these “logic components” and “presentation components”. This matches what I originally meant by “smart” and “dumb” components (before Redux or support for functional components in React) although I'm not sure I'm fond of these names.

[acdlite]

Worth mentioning that the Flux website also uses the terms controller-view and view. I actually think those are good descriptors, except they reek of MVC.

[gnoff]

In my use I've started naming my connected components ThingConnector. If there is concern with renaming 'smart' to 'connected' perhaps 'connector' is a less ambiguous since it is a component which is intended to be connected. I also favor dropping 'dumb' as a descriptor. Every component that isn't a connector is 'dumb' or 'plain' implicitly.

In practice I connect things deeper in my tree and I don't name them al 'Connector' but then I am already eschewing the smart/dumb pattern there anyway

[gnoff]

For what it's worth I also like calling them container components.

[dvdzkwsk]

I agree with @gnoff about using the term "container." The terms "smart" and "dumb" definitely get the point across, but "container" is used elsewhere as @gaearon said (I'll throw recompose into the list as well) and does a better job describing the fact that the component is in fact wrapped by a higher-order component.

Personally I think it helps demonstrate the fact that everything is in fact a "dumb" component, but some of those are just wrapped in a container.

[gaearon]

Presentational Components and Container Components it is.
PRs to update docs here and in Redux docs are welcome.

[mik01aj]

Hey, how about adding a reference to other-names-of-the-same-thing to the docs to avoid further confusion?

Presentational Components	Container Components
dumb	smart
view	controller-view
stateless	stateful

[gaearon]

Happy to accept a PR.

However as I wrote above, presentational components aren't necessarily stateless.
It's just they're not concerned with fetching / retrieving data. But they may have local UI state.