In React/Redux app, when should I pass down a prop explicitly versus picking it up from global state using mapStateToProps?

Question

I am building my first React-Redux app and in many cases I have a choice of either doing <PaginationBox perPage={perPage} /> or having <PaginationBox /> and then do

function mapStateToProps({pagination: {page}}) {
  return {
    pageNumber: page + 1
  };
}

What are the implications of using one way or another and when should I prefer one over the other?

Are there any established best practices on how to pick up props? I feel a little bad every time I use mapStateToProps in some deeply nested component because it feels like the component gets coupled to the state of the particular page/app.

Answer 1

There is no single good answer. Per the Redux FAQ at http://redux.js.org/docs/FAQ.html#react-multiple-components , it's up to you to decide where in your component hierarchy it makes sense to connect a component. It could be at the "LeftSidebar / RightMainPanel" level, or it could be much more granular. In some cases, such as trying to optimize a list for performance, you might have the List itself be connected and retrieve the item IDs, and every ListItem would themselves be connected and retrieve their own data by ID.

For this particular case, I'd probably lean towards having a <PaginationBox /> be connected, and render stateless functional <PaginationItem /> components as necessary, mostly just because the individual items aren't going to need any real information attached other than a number and a link to click. But, that's just an opinion.

Answer 2

Did you already have a look into the presenter/container components pattern? There exist multiple good articles around this pattern, which give you most of the time a good idea of when to have a presenter or container component

My advice:

Start with one container component (which has mapStateToProps and mapDispatchToProps) at the top of your component hierarchy. Below stick to presenter components which only receive props and actions. There will be a time when you notice that (A) one presenter component needs a lot of properties/actions itself or that (B) you are passing properties/actions for too many levels down and only some of them are grabbed by components in between.

Then you start to exchange presenter with container components for fat components (A). When there are still too many actions/properties passed (B), you need to think about more container components, which take care of avoiding too deep props/actions passing.

But your first rule could be: one container component on top, all components below are presenters.