This is a fantastic pattern - just not for trivially simple logic.
It's a really great for passing in parameters to a component that might use some context (or other data source) whereas your parent component doesn't need to use that context. It allows all of the logic of conditional rendering to be then tucked away in one place and tested separately.
This is a fantastic pattern - just not for trivially simple logic.
It's a really great for passing in parameters to a component that might use some context (or other data source) whereas your parent component doesn't need to use that context. It allows all of the logic of conditional rendering to be then tucked away in one place and tested separately.
great remark, I will have to do my own research on that as your comment gave me some ideas and a different perspective on the whole thing.
By the way, this is far from a "novel" pattern, but it sounds like it might be a lightbulb moment for you in terms of separating concerns.
Take a look at some very popular conditional components that you've probably already used:
MaterialUI's Hidden component: github.com/mui-org/material-ui/blo...
It uses the theme context internally and the media-query props you provide it to determine if a child should be rendered.
React Router's Route component: github.com/ReactTraining/react-rou...
It uses the router context and the
pathparameter you pass in to determine if the child (or render of Component props) should be rendered.