If you're a resident of redux land, you've probably heard the tale of container components vs presentational components. The latter has no knowledge of redux, does the heavy lifting rendering wise, and communicates with the former via callbacks. The former knows about redux, state, actions, the store, etc. There's a clear demarcation between the two sides. That being said, sometimes you don't need presentational components. If the rendering is simple enough, you can "just do it". You hear a recommendation, guide line, or best practice suggested by a framework author, and over time you apply it rigorously; treating it as a fact of life. I'm guilty as well (although I go out of my way not to be). Ultimately you have to be pragmatic about how you apply idioms and best practices. Sometimes it's worth asking "does this really make sense". I found myself wondering just that when I was staring at a container component that was a mirror image of the presentational component it delegated to. Same prop types, both one line or rendering, and both destructuring the same props verbatim. But if felt good to be following the suggestion. I'm doing ultimate redux now. No one can argue with me or call me out about "hey, you know you should never do X when using redux. it's an anti-pattern". Or "@gaeron said you should never do X". "X is bad"." Feels good, doesn't it? Until you have 10 extra files of nonsense lying around providing 0 value. If you can do away with the extra level of indirection, then that's a "much win". I feel pretty good about these two commits:
Extra cruft and boilerplate gone. One less file. Everything moving that much closer to the surface. Again, this is a "much win". It's no big deal if the container component takes on more rendering load in the future. Just extract the relevant markup, add the new file to encompass the presentational component, retrofit it with the new, and call it a day. Until that time, take all things with a grain of sea salt, and just stick to YAGNI and KISS. You'll go far in this life, Young Luke.
EDIT: See the official redux documentation for further details as the core maintainers do a much better job at explaining this than I do.. I don't see the introduction of react-hooks, the useRedux hook, etc. changing these core concepts going forward. Presentational vs Container components are more design/concept based and independant of react core and its newer features like fiber and concurrent mode as opposed to there being a direct correlation between the two. Thanks!