I have a quick question, maybe someone can clarify it for me.
Im doing the headless component portion of Advanced React. I think i fully understand the concept of using children and then Context APi in order to pass state to other components instead of state drilling etc… What i can’t understand is the benefit of building an application this way. Nesting everything, when it would be much easier to create that star component in less components.
Im starting to think im missing a point here. Is this just an exercise of what is possible or you actually build features this way, when would i use this over less components and less code?
Is the goal to build logic/functionality in these components and then re-use them throughout the app?
function App() {
return (
<>
<Toggle.Button>
<Toggle.On>
</Toggle.On>
<Toggle.Off>
</Toggle.Off>
</Toggle.Button>
</>
)
}
Maybe someone can give me an example of a clear problem where this solution would be suitable?
I haven’t coded in React in ages so I might be not fully correct but I think I can give some context around this. I think what’s tripping you up is the example in the lesson is pretty simple so in terms of scaling and reusability so it might feel actually more complicated as Bob stated. For a growing code base though you would see the effect more in play.
The main benefit for building it out like this would be reusability, logic seperation, and ease of testing. When you build a headless component, you separate the logic from the presentation to allow you to reuse the same logic in different parts of your application without duplicating code. It exhibits the concept of Seperation of Concerns which makes your code more modular and easier to understand.
Testing can also be easier when your code base is much larger. You can test the logic in isolation, and the presentation components become simpler to test as they mostly deal with rendering and user interactions.
With the code in the lesson, you can easily reuse the ToggleButton component in different parts of your application while maintaining a single source of truth for the toggle state in the Toggle component.For small codebases this abstraction can makes things confusing but if you were to plan out an app and it’s features, identify all the different components that you may require, it will probably make more sense to you since you would know when and why you would use it.
For example - a search bar is present on every page of my app. The logic for this might be pretty heavy so I would already know I would build a component for this. At first, the search bar component might make it complex if I were to just have a blank page (I could just build it in the app page code itself) but when I build out the rest of my app page, it would make things easier to handle when I off load the search bar code logic out of this app page code since this code (for the page) in itself might be a lot too.