A Better Frontend Component Structure: Component Trees
The simple application structure above gives little insight into how these components interact. For example, you might guess that Layout.tsx imports Footer.tsx and Header.tsx, which in turn might import BoxContainer.tsx. But this is not clear from the file structure alone. What’s worse, as your application grows, the list of components will become increasingly more difficult to deduce how they’re connected. A common first thought might be to organize components into semantically correct directories Naming things is hard. As a developer, you try to create good names and classifications for each directory, like containers, headings, etcetera.
The problem is that you need to think of even more classifications for the directories, not just the component names. You will often be tempted to say, “You know what, I’ll just move this to the common directory.” Having common directories is an anti-pattern to what you’re trying to achieve, but with this structure, it’s simply too easy to be drawn into it. And, when your application gets large enough, you might have to start considering creating another level of directories to keep things organized. This requires even more name creation, increasing the cognitive load for repository users. Ultimately, this approach doesn’t scale well.
0 Comments