mirror of
https://github.com/twentyhq/twenty
synced 2026-04-21 13:37:22 +00:00
5d438bb70c
## Summary - **New Getting Started section** with quickstart guide and restructured navigation - **Halftone-style illustrations** for User Guide and Developer introduction cards using a Canvas 2D filter script - **Removed hero images** (`image:` frontmatter + `<Frame><img>` blocks) from all user-guide article pages - **Cleaned up translations** (13 languages): removed hero images and updated introduction cards to use halftone style - **Cleaned up twenty-ui pages**: removed outdated hero images from component docs - **Deleted orphaned images**: `table.png`, `kanban.png` - **Developer page**: fixed duplicate icon, switched to 3-column layout ## Test plan - [ ] Verify docs site builds without errors - [ ] Check User Guide introduction page renders halftone card images in both light and dark mode - [ ] Check Developer introduction page renders 3-column layout with distinct icons - [ ] Confirm article pages no longer show hero images at the top - [ ] Spot-check a few translated pages to ensure hero images are removed 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: github-actions <github-actions@twenty.com>
113 lines
3.6 KiB
Text
113 lines
3.6 KiB
Text
---
|
|
title: Folder Architecture
|
|
icon: "folder-tree"
|
|
info: A detailed look into our folder architecture
|
|
---
|
|
|
|
|
|
In this guide, you will explore the details of the project directory structure and how it contributes to the organization and maintainability of Twenty.
|
|
|
|
By following this folder architecture convention, it's easier to find the files related to specific features and ensure that the application is scalable and maintainable.
|
|
|
|
```
|
|
front
|
|
└───modules
|
|
│ └───module1
|
|
│ │ └───submodule1
|
|
│ └───module2
|
|
│ └───ui
|
|
│ │ └───display
|
|
│ │ └───inputs
|
|
│ │ │ └───buttons
|
|
│ │ └───...
|
|
└───pages
|
|
└───...
|
|
```
|
|
|
|
## Pages
|
|
|
|
Includes the top-level components defined by the application routes. They import more low-level components from the modules folder (more details below).
|
|
|
|
## Modules
|
|
|
|
Each module represents a feature or a group of feature, comprising its specific components, states, and operational logic.
|
|
They should all follow the structure below. You can nest modules within modules (referred to as submodules) and the same rules will apply.
|
|
|
|
```
|
|
module1
|
|
└───components
|
|
│ └───component1
|
|
│ └───component2
|
|
└───constants
|
|
└───contexts
|
|
└───graphql
|
|
│ └───fragments
|
|
│ └───queries
|
|
│ └───mutations
|
|
└───hooks
|
|
│ └───internal
|
|
└───states
|
|
│ └───selectors
|
|
└───types
|
|
└───utils
|
|
```
|
|
|
|
### Contexts
|
|
|
|
A context is a way to pass data through the component tree without having to pass props down manually at every level.
|
|
|
|
See [React Context](https://react.dev/reference/react#context-hooks) for more details.
|
|
|
|
### GraphQL
|
|
|
|
Includes fragments, queries, and mutations.
|
|
|
|
See [GraphQL](https://graphql.org/learn/) for more details.
|
|
|
|
- Fragments
|
|
|
|
A fragment is a reusable piece of a query, which you can use in different places. By using fragments, it's easier to avoid duplicating code.
|
|
|
|
See [GraphQL Fragments](https://graphql.org/learn/queries/#fragments) for more details.
|
|
|
|
- Queries
|
|
|
|
See [GraphQL Queries](https://graphql.org/learn/queries/) for more details.
|
|
|
|
- Mutations
|
|
|
|
See [GraphQL Mutations](https://graphql.org/learn/queries/#mutations) for more details.
|
|
|
|
### Hooks
|
|
|
|
See [Hooks](https://react.dev/learn/reusing-logic-with-custom-hooks) for more details.
|
|
|
|
### States
|
|
|
|
Contains the state management logic. [Jotai](https://jotai.org) handles this.
|
|
|
|
- Selectors: Derived atoms (using `createAtomSelector`) compute values from other atoms and are automatically memoized.
|
|
|
|
React's built-in state management still handles state within a component.
|
|
|
|
### Utils
|
|
|
|
Should just contain reusable pure functions. Otherwise, create custom hooks in the `hooks` folder.
|
|
|
|
|
|
## UI
|
|
|
|
Contains all the reusable UI components used in the application.
|
|
|
|
This folder can contain sub-folders, like `data`, `display`, `feedback`, and `input` for specific types of components. Each component should be self-contained and reusable, so that you can use it in different parts of the application.
|
|
|
|
By separating the UI components from the other components in the `modules` folder, it's easier to maintain a consistent design and to make changes to the UI without affecting other parts (business logic) of the codebase.
|
|
|
|
## Interface and dependencies
|
|
|
|
You can import other module code from any module except for the `ui` folder. This will keep its code easy to test.
|
|
|
|
### Internal
|
|
|
|
Each part (hooks, states, ...) of a module can have an `internal` folder, which contains parts that are just used within the module.
|
|
|