React Hooks: What will happen to the Container/Presenter Pattern?

This is a great candidate for a DevTip!

[esabaliauskas]

The problem with this example is that it is too simple and usually Container Presenter pattern is used for more complex code, so not all decisions made here while refactoring would be good when dealing with real world examples. Of course you don't need a separate component to render a simple button, but try returning a table with multiple rows with custom styles. Also, what if the container state has about 10 state variables and multiple onChange function? We would end up with multiple useState variable + function pairs, so not much improvmenet. Also, single file would be prety long, so separating custom hook from view component would be useful. So this example gives an illusion that hooks drasticly reduce complexity and code lines.

[dealloc]

Separating logic from UI is very valuable in a medium to a large team/project where you have many people working on separate areas of the app. It makes the logic, code reviews and tests more focused and easier to understand without having to blend the two.

[SeanLazer]

Hey Kent, thanks so much for the thorough answer! I agree that the Presenter/Container pattern looks pretty ridiculous when it's applied to such a small/focused component, but I've found it really useful when dealing with some of my large top-level components (i.e. an index component that needs to fetch data, be aware of user-applied filter state, paginate results, and render the actual list of items). I also use styled-components which means having CSS-in-JS declarations at the top of the file, and typescript which means having interface declaration for Props and State. When files start to push 150-200 lines but are still dealing with closely related concepts, or when nested render props have me tabbing 12 times before I can even start writing my markup it just feels like some separation needs to happen for hygiene purposes. I definitely wouldn't recommend jumping on the Presenter/Container pattern by default but I'm pretty surprised that you don't use it at all! About to go watch your "React Component Organization Tips" video to see if there's some alternate approaches I hadn't considered. Thanks again for the fast/great answer!

[TheKevinMeinhardt]

@kent @2:50 you explain the exact value in using container presenter. You would be able to refactor the way you do logic without having to look at or touch your presenter/layout component. Don’t we also get testing benefits by isolating logic and ui? Think about a disabled button. If I have a disabled prop testing is easy, I just declare the state to my ui and confirm the button is disabled. If the logic controlling my disabled prop is internal to the presenter component and depends on some value in local store that a hook is reading, then my test requires a lot more work to prove my button is disabled. What do you think about this?

[TheLexuguin]

Would be interesting to see how to test this approach.

[mattmarkus]

Can someone tell me if the Counter component that uses the useCounter hook unmounts, will that state be removed? I have a tabbed dialog in material-ui and when you switch tabs the component in the tab unmounts. To address this I'm declaring initial state and updater in the parent and passing them as props to the child in the tab, which works, but I'd rather not create state in the parent and pass them as props if I don't have to. I suppose I could create a hook for that state and grab it in the parent and still pass it as props to the child. But I'm just wondering: if component A uses a hook for some state and then component A unmounts, the state will be gone right?

[jason_v]

It'd be a lot more helpful if you specified the value that you see or don't see in the various options instead of just telling us that you do or do not see value. Just telling us that you think it's "so clean!" and "awesome!" is pretty useless.

[maxhine]

I tried to put `increment` in a child-component and `count` in another child-component, and each child-component reference the userCounter() for what it needs, and I found the `increment` action did update the internal value, but `count` did not get rendered by a parent component.

[Vladimir___]

I think you already answered this, but can you please say what is the name of extension with fonts on the default tab

[Euquila]

I have to say I completely *disagree* with the anti-container mood of this video. If you plan to develop a medium to large scale app, than separating your skeleton (dumb puppet components) from the blood (puppeteer logic) is so vital! Hooks or no hooks is irrelevant to this conversation. I do appreciate how you mention that hooks can be "focused" to a specific component. So many people have this "hooks need to be generic" idea, which is completely false.

[tagdocker]

Foo Bar examples depend on the level that you are catering to. If you are explaining a whole new concept, like what react component structure means to a novice programmer then I would go with a realistic example. But if you are showing example of remixing existing known patterns and using them in a new way, then foo bar is sufficient for understanding.

During the unveiling of Hooks at the JS Conf Dan and the team have been using real examples, because it's a much easier thing to grasp hands on. Had he shown us Foo Bars, then hooks might have been far less popular

[Colstonewall]

Still being fairly new to React, I don't quite understand how Hooks helps us so much. It's my understanding that Hooks simply allow State to be used in Functional Components. At this point in my React learning, I don't see why this is such a big deal? I've seen people say "we won't need to use Redux anymore thanks to Hooks" and other similar comments. How is this so? I don't get that, Kent? Any suggestions you have would be greatly helpful!

[stabMyFaceOff]

What do you mean you don't use the container pattern???
Ever hear of separation of concerns.
Bet your apps are a nightmare to read.

[valle]

The only benefit of the custom hook that you've made, is that it's a very clean and concise Counter component. Is it same as if you merge the CounterContainer (class) with the "dumb" Counter? Yes it is! Only that it's not concise and looks pretty ugly. In both of the cases the logic coupled with the UI. No SRP. Conclusion: Hooks won't let you separate concerns and Container/component pattern have nothing to do with hooks approach.
Your video just leads into confusion.