Where should be the line to separate stateful and stateless component in React?

Question

React encourages the use of stateless components as much as possible and have a stateful parent component managing them. I understand that this can make the stateless components more reusable, and easy to manage. However, to the extreme, we can always put the state at the top level component, like App.js, and pass down information and callbacks through a long props chain. And if using Flux, the actions can always be dispatched in it too (executed through callbacks).

So I'm wondering what's line to separate stateful and stateless components? And if using Flux, where should the Actions to be dispatched?

--- Add an example ---

Say I have a google docs like web app that have a tool bar and displayed content. I imagine we will have the component structure.

<App>
    <Toolbar />
    <Content />
</App>

The tool bar has buttons that will affect the display content, say the bold text button.

So should the App pass down onButtonPressed callback props to Toolbar and dispatch Actions in itself, or should let the Toolbar to do it itself?

Should the App pass down contentString props to Content, or let Content itself listen to Store changes?

Thanks!

Digressive

Answer 1

From my point of view, a simple application could use the pattern of Flux in that way :

1. Children emit actions.
2. The application listens to stores and propagates processed data to his children.

With that approach, you have the stateless component, but with a good code organisation without the callback props. But both of your propositions are also correct, it's a decision that you make regarding the size and needs of your application.

If the component that you build will be used outside of your application, don't use flux as much as possible and let the developer choose the wanted approach for his needs.

Galoshes

Answer 2

It's a good question, and it is being solved differently even between different Flux implementations.

I prefer having my state in one high-level component, that sees the "big picrure", and propagate data using props to all the low-level ones. In a good React app, most of the components shouldn't "care" where the data is coming from. Having a one good structured model instead of several fragmented ones also proves itself to be beneficial so far. (by the way, that can be achieved even using several stores, the high-level component could listen to all of them, and virtually "hold" this big model).

Regarding actions - I prefer having all my "dumb" visualization/ui/display components work with callback props. That way it is easier to re-use them, and it is a good separation of concerns. In richer components that hold a bit of business logic, I call Reflux actions directly. Usually those are also container components themselves to aforementioned "dumb" ui controllers.

So bottom line - data should flow from as high as possible, actions can be fired from lower components, but always check whether you can achieve the same result with callback props.

To your question - the Toolbar is a complex enough component to have ToolbarActions of its own and call them directly. But the Content component should definitely get its data from above. It's also easier to reason the data flow that way, when the app gets complicated.

Hope that helps. The whole Flux thing is still an art in progress...

Windbound