React Hooks and Container/Presenter Component Pattern

[SeanRoberts]

Hi Kent,

I had a question for you on something I haven't really seen anyone talking about yet. With React Hooks dropping soon, what do you think is going to happen to the Container/Presenter component pattern? I can see it going a couple of different ways:

1. No more separation at all, just declare your hooks stuff at the top of your function component and keep everything together. In some cases the render props pattern allows/nudges us to work this way already, but when you have a component that uses a few different render prop components, plus has a decent amount of markup things can get really unwieldy. I imagine the result would be the same if you had a lot of stateful logic sitting at the top of your function component.

2. Keep the pattern as-is, except the container component does its heavy lifting through hooks, and then passes the values down as props to the presenter component. Essentially the presenter component remains untouched, but the container component changes its implementation.

3. Instead of creating a container component, create a custom hook that's only used by your presenter component, allowing you to keep your stateful logic in a separate file from your presentation but not requiring the creation/rendering of two separate components.

Any thoughts on this? Do you think one of these patterns will be dominant? Any other things I may not have considered?

Thanks!

[kentcdodds]

Hey Sean!

Great question. I answered this in today's devtip

[doasync]

I beleave separation of concerns is a good practice. My recommendation is to stick with the second option.

I have created a Todo App using hooks to show how you can separate not only the view layer but also your business logic. Check it out to see if having pure presentational components is a good idea:
https://codesandbox.io/s/934qwo74ko

[kentcdodds]

Thanks for sharing your perspective @doasync. When I look at that I still see very little value separating the view from the logic 🤷‍♂️

[SeanRoberts]

Is there a point where your component files reach a certain size and you start to get a little itchy about it? I think the desire to create these separations comes from a feeling I get when my components reach 100+ LOC and I can't see any clear places to extract concerns. For me it's typically top-level "page" components that are responsible for fetching data and then passing it down to all the major child-components on a page. Maybe there are other architectural solutions to that problem... or maybe it's just okay to have a few big modules?

[kentcdodds]

I like separating concerns in my components. So if I see there's a clear separation of concerns then I'll make a split. NOTE: logic and presentation are not necessarily separate concerns!

I definitely have seen some situations where separating logic and presentation was useful, but it's not a default for me. The size of the module doesn't bug me all that much. Though I'm pretty against having huge files. I shudder when I think back on that backbone view I worked on that was 3k lines long. But the problem wasn't so much how long that file was but how many concerns were being mixed. What makes something hard to maintain isn't how many lines it is but the complexity those lines represent.

[Voronar]

I think the second approach is more scalable, because in this case Presenter Component has no external dependencies (hooks). Its just pure function with data/actions as arguments.