The project tries to follow a directory structure that mirrors the components structure of the design system/component library. The library divides components into 2 groups:
- Atomic Components (icons, buttons, inputs)
- UI Components (forms, cards, timers, etc.)
The codebase adds a further distinction between these 2 groups which are represented by the folders in src/:
- Components
- Icons
- Inputs
- UI
- Layouts
- Pages
The folders UI, Layouts, and Pages can then be divided along the main routing of the app: Home, Library, Training, User, and Auth.
It can be a bit confusing at first where a particular component should go so I'll go through some notable folders and try to describe what they should contain.
Components in UI and Layouts may seem to overlap but the clearest distinction is in their imports and where they are imported.
A UI component only ever imports from src/components (minus the UI folder) and is never directly imported into a Page, only a Layout component.
UI components can be described as 'molecules' according to Brad Frost's division.
Your component should be in this folder if it builds up atomic components into more complex layouts. They tend to mainly display information, received through props, or expose custom v-model logic. Therefore, a UI component has very little of it's own data and few methods.
Layout components are those that are meant to be imported into a Page.
Their main focus, as their name implies, is to manage the layout and positioning of their inner components. Aside from that, they are similar to UI components in that they have little data and only a few methods.
Generally, the most complex logic they have governs the v-model emit function.
Page components serve as the access points of the applications, they directly map to the app's URL routes.
Their second purpose is to serve as the data origin, they hold the main data to which all the layouts v-model to. This makes it the point from which you would generally make a dispatch to the store.
Similar to the other components, they are rather light in logic, mostly dealing with which Layout component should be rendered, like a tab interface controller.
This file and folder division mainly aims to reduce mental friction between the design system and the codebase but it also helps ensure that ui components are in charge of the interface and as little else as possible. You might have noticed that all these components handle little functionality, so where does it all go then?
These components all go into src/components/renderless, they are in charge of handling all the more advanced and involved logic relating to the data that is found inside their corresponding interface component.
Their format is rather standard, these are renderless components that expose helper functions through v-slots. The importing component can then offload things like validation, conditional data based values, API calls, and more.