Presentational/Container components are known as a good separation of concerns pattern in React, and if we search about the topic you'll definitely find Dan Abramov's post regarding that.
But quite some time ago he then updated that post with a statement that can be interpreted that due to the recent adaptability to using Hooks, the presentational/container components pattern is not as recommended as it was before. Since we can create custom hooks that contain that code instead.
How do you interpret what he meant by that?
Having a gigantic custom hook that does all that logic and returns a bunch of variables? And then calling that hook in a component?
Personally I still find container components useful as it separates what is business logic (calling apis and handling the result flow of that) from "UI logic" (storing state for a tab, an animation)
It's easier when you're working with a large scale app to find where the API, redux or graphql calls are being done if they're in its own place, and always following the same pattern. But if we didn't have that, how would we solve this problem and not having a mess of multiple components calling apis and doing its own thing everywhere in the app/tree?
I'm asking this because even when still using container components to only fetch an api and/or get the redux state, and keeping everything tidy, sometimes I still find useful for some components to call the API and do what a "container" would do themselves, to avoid having to pass down props or making a container TOO big/confusing. And it is kind of conflicting having just some components do that and the rest stay in a container component. How would you handle that?