Components structure in Twenty codebase — Part 1.0
Components structure in Twenty codebase — Part 1.1
Components structure in Twenty codebase — Part 1.2
In Part 1.2, we reviewed how the routes are configured in the twent-front package. In this article, we review the components structure in the following components:
import { SubMenuTopBarContainer } from '@/ui/layout/page/components/SubMenuTopBarContainer';import { SettingsPageContainer } from '@/settings/components/SettingsPageContainer';import { WorkspaceMemberPictureUploader } from '@/settings/workspace-member/components/WorkspaceMemberPictureUploader';import { EmailField } from '@/settings/profile/components/EmailField';import { NameFields } from '@/settings/profile/components/NameFields';import { SetOrChangePassword } from '@/settings/profile/components/SetOrChangePassword';import { Section } from 'twenty-ui/layout';import { H2Title, IconShield, Status } from 'twenty-ui/display';import { UndecoratedLink } from 'twenty-ui/navigation';
There were three components imported from settings/profile/components. Reusable, high level components are defined at package level. For example, twenty-ui related imports.
I think this is a great example demonstrating “place things where they belong”.
And from what I have seen, you colocate components depending on their nature but reuse among these folders as you see fit. For example, DeleteProfile was imported from settings/profile and WorkspaceLogoUploader is imported from settings/workspace.
I spent 200+ hours analyzing Supabase, shadcn/ui, LobeChat. Found the patterns that separate AI slop from production code. Stop refactoring AI slop. Start with proven patterns. Check out production-grade projects atthinkthroo.com