When you want to have "early return" in a component, it's possible to just split the component into two to introduce an "inner" component that contains whatever comes after the early return point in the original component.
Any local variables from before the early return then need to be passed as props to the new inner component.
However, naming this inner component is always an issue for me. Typically I just name them Inspector2, Inspector3, etc. until I have an implementation that works. Then I can start thinking about how to refactor the implementation into something that I can give sensible names.
It's really a code transformation similar to async/await where you derive a state machine from a block of code by identifying transition points. In async/await you have transitions at the await points; in components you have transitions at the early return points. In async/await, no one is forcing you to name the individual states or even write them out explicitly - the compiler takes care of it. Then why do I have to write out the state machine explicitly and name the states explicitly for function components with early return? I would love for React to have some facility like "Consider the rest of this component as a new sub-component; as if this component now returns a single Element pointing to whatever is in the rest of this component". But it's probably a Hard Problem™.
This is exactly the use case for HOCs and why I continue to be old man yells at cloud about how the "hooks replace(d) HOCs" zeitgeist is missing a key benefit.
Wrapping components lets you have layers that don't have to care about what's going on inside. HOCs just let you write those layers in a way that can be composed. In your example, `isVisible` could be its own HOC, and then the inner component can have whatever name it needs.
When you want to have "early return" in a component, it's possible to just split the component into two to introduce an "inner" component that contains whatever comes after the early return point in the original component.
Any local variables from before the early return then need to be passed as props to the new inner component.
However, naming this inner component is always an issue for me. Typically I just name them Inspector2, Inspector3, etc. until I have an implementation that works. Then I can start thinking about how to refactor the implementation into something that I can give sensible names.
It's really a code transformation similar to async/await where you derive a state machine from a block of code by identifying transition points. In async/await you have transitions at the await points; in components you have transitions at the early return points. In async/await, no one is forcing you to name the individual states or even write them out explicitly - the compiler takes care of it. Then why do I have to write out the state machine explicitly and name the states explicitly for function components with early return? I would love for React to have some facility like "Consider the rest of this component as a new sub-component; as if this component now returns a single Element pointing to whatever is in the rest of this component". But it's probably a Hard Problem™.