At this point the container is already a chummy mix of model, view and controller logic. But it's a manageable component. However, if we keep adding features to this container – a form for posting new comments, server side paging & filtering, etc – we're going to need some kind of code architecture to maintain it.

If we decide to add paging controls and a "New comment" button to the control bar, the amount of children here would warrant wrapping them in a separate sub component, e.g. CommentListControlBar .

Doing this we run in to a situation where we have event handlers in a container (that holds the state) which needs to be props on some controls, but to get them there we need to pass them via the props of our new sub component. This is called state hoisting and is for some reason an encouraged pattern in React (another example in the official docs, and a good visualisation here in #1).

There are two problems with this as I see it. First, I just don't like the overhead of passing all the handlers down my view component tree.

Second – and most importantly – our view components are now in charge of how we can interact with them. Doing this makes our view tightly coupled with our controller logic, removing one of the main benefits of MVC.

If I want some functionality on click, keydown, mouseover, drag, etc – it's not enough to simply add event handlers in my controller, I also need to modify all my view components, making them less reusable.

So let's see how we can avoid this by refactoring a bit.