mirror of
https://github.com/twentyhq/twenty.git
synced 2024-09-11 15:35:36 +03:00
changes as per vale warnings (#2353)
* changes as per vale warnings * changes acc to feedback
This commit is contained in:
parent
7623e7b7f9
commit
398a8d732d
42
.github/CODE_OF_CONDUCT.md
vendored
42
.github/CODE_OF_CONDUCT.md
vendored
@ -1,29 +1,22 @@
|
||||
# Contributor Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
## Twenty's Pledge
|
||||
|
||||
As contributors and maintainers of this project, we pledge to make participation in our
|
||||
community a harassment-free experience for everyone, regardless of age, body
|
||||
size, visible or invisible disability, ethnicity, sex characteristics, gender
|
||||
identity and expression, level of experience, education, socio-economic status,
|
||||
nationality, personal appearance, race, religion, or sexual identity
|
||||
and orientation.
|
||||
The contributors and maintainers of this project pledge to ensure a harassment-free experience for everyone in the community. This commitment applies to individuals of all backgrounds, including age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity, experience, education, socio-economic status, nationality, appearance, race, religion. It also applies to individuals of all sexual identities and orientations.
|
||||
|
||||
We pledge to act and interact in ways that contribute to an open, welcoming, friendly,
|
||||
diverse, inclusive, and healthy community.
|
||||
The focus of both contributors and maintainers is on acting and interacting in ways that promote an open, welcoming, friendly, diverse, inclusive, and healthy community.
|
||||
|
||||
## Our Standards
|
||||
## Twenty's Standards
|
||||
|
||||
Examples of behavior that contributes to a positive environment for our
|
||||
Examples of behavior that contributes to a positive environment for this
|
||||
community include:
|
||||
|
||||
* Demonstrating empathy and kindness toward other people
|
||||
* Being respectful of differing opinions, viewpoints, and experiences
|
||||
* Respectfully giving and gracefully accepting constructive feedback
|
||||
* Accepting responsibility and apologizing to those affected by our mistakes,
|
||||
* Respectfully giving and accepting constructive feedback
|
||||
* Accepting responsibility and apologizing to those affected by mistakes,
|
||||
and learning from the experience
|
||||
* Focusing on what is best not just for us as individuals, but for the
|
||||
overall community
|
||||
* Focusing on what's best, not just for each individual but also for the community
|
||||
|
||||
Examples of unacceptable behavior include:
|
||||
|
||||
@ -34,36 +27,29 @@ Examples of unacceptable behavior include:
|
||||
* The use of aggressive language
|
||||
* Publishing others' private information, such as a physical or email
|
||||
address, without their explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
* Other conduct inappropriate in a professional setting.
|
||||
|
||||
## Enforcement Responsibilities
|
||||
|
||||
Community leaders and maintainers of this repository are responsible for clarifying and enforcing our standards of
|
||||
acceptable behavior and will take appropriate and fair corrective action in
|
||||
response to any behavior that they deem inappropriate, threatening, offensive,
|
||||
or harmful.
|
||||
Community leaders and maintainers of this repository are responsible for clarifying and enforcing Twenty's standards of acceptable behavior. They will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
|
||||
|
||||
Community leaders and maintainers of this repository have the right and responsibility to remove, edit, or reject
|
||||
comments, commits, code, issues, and other contributions that are
|
||||
not aligned to this Code of Conduct, and will communicate reasons for moderation
|
||||
decisions when appropriate.
|
||||
Community leaders and maintainers of this repository have the right and responsibility to remove, edit, or reject comments, commits, code, issues, and other contributions that aren't aligned with this Code of Conduct. They will also communicate reasons for moderation decisions when appropriate.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies within all community spaces, and also applies when
|
||||
an individual is officially representing the community in public spaces.
|
||||
Examples of representing our community include using an official e-mail address,
|
||||
Examples of representing this community include using an official e-mail address,
|
||||
posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||
This Code of Conduct is an adaption of the [Contributor Covenant][homepage],
|
||||
version 2.0, available at
|
||||
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
|
||||
|
||||
Community Impact Guidelines were inspired by [Mozilla's code of conduct
|
||||
Community Impact Guidelines draw inspiration from [Mozilla's code of conduct
|
||||
enforcement ladder](https://github.com/mozilla/diversity).
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
|
24
.github/CONTRIBUTING.md
vendored
24
.github/CONTRIBUTING.md
vendored
@ -1,10 +1,12 @@
|
||||
# Contributing to Twenty
|
||||
|
||||
|
||||
Thank you for considering contributing to Twenty! We welcome all types of contributions from the community to help us build and improve our open-source CRM platform. This guide outlines the process for contributing to our project. Please make sure to go through the [documentation](https://docs.twenty.com) before making your contribution.
|
||||
Thank you for considering contributing to Twenty! All community contributions are welcome.
|
||||
|
||||
This guide outlines the process for contributing to this project. Please make sure to go through the [documentation](https://docs.twenty.com) before making your contribution.
|
||||
|
||||
|
||||
> And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:
|
||||
> And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation:
|
||||
> - Star the project
|
||||
> - Tweet about it
|
||||
|
||||
@ -16,9 +18,9 @@ Thank you for considering contributing to Twenty! We welcome all types of contri
|
||||
|
||||
Good first issues are a great way to start contributing to the project and get familiar with the codebase. Here's how to find them:
|
||||
|
||||
1. Visit the "[Issues](https://github.com/twentyhq/twenty/issues)" tab on our [repository](https://github.com/twentyhq/twenty).
|
||||
1. Visit the "[Issues](https://github.com/twentyhq/twenty/issues)" tab on the main [repository](https://github.com/twentyhq/twenty).
|
||||
2. Use the "Labels" filter and select "[Good First Issue](https://github.com/twentyhq/twenty/labels/good%20first%20issue)" to see a list of beginner-friendly tasks.
|
||||
3. Choose an issue that interests you, fork the project, and start working on it. Once you solve and test the issue, open a PR and we'll review it.
|
||||
3. Choose an issue that interests you, fork the project, and start working on it. Once you solve and test the issue, open a PR for review.
|
||||
|
||||
<br>
|
||||
|
||||
@ -38,7 +40,7 @@ cd twenty
|
||||
```
|
||||
|
||||
|
||||
3. **Make Changes:** Make your desired changes and ensure that your code adheres to our coding standards.
|
||||
3. **Make Changes:** Make your desired changes and ensure that your code adheres to Twenty's coding standards.
|
||||
|
||||
|
||||
4. **Test Locally:** Test your changes locally to ensure they work as expected.
|
||||
@ -58,28 +60,28 @@ git push origin branch-name
|
||||
```
|
||||
|
||||
|
||||
7. **Create a Pull Request:** Go to the original Twenty repository and create a pull request. Please provide a detailed description of your changes. To accept your pull request, we need you to sign a CLA.
|
||||
7. **Create a Pull Request:** Go to the original Twenty repository and create a pull request. Please provide a detailed description of your changes. To have your pull request accepted, you must sign a CLA.
|
||||
|
||||
|
||||
8. **Code Review:** Your pull request will undergo a code review. Be prepared to make any necessary adjustments based on feedback.
|
||||
8. **Code Review:** Your pull request will undergo a code review. Note that you might need to make any necessary adjustments based on feedback.
|
||||
|
||||
|
||||
9. **Merge:** Once your pull request is approved, it will be merged into the main repository.
|
||||
9. **Merge:** Once approved, maintainers will merge your pull request into the main repository.
|
||||
|
||||
|
||||
<br>
|
||||
|
||||
## Code of Conduct
|
||||
|
||||
Please note that by contributing to this project, you are expected to follow our [Code of Conduct](./CODE_OF_CONDUCT.md). We strive to maintain a welcoming, friendly, and inclusive community for all contributors.
|
||||
Please note that by contributing to this project, you're expected to follow Twenty's [Code of Conduct](./CODE_OF_CONDUCT.md). All maintainers strive to maintain a welcoming, friendly, and inclusive community for all contributors.
|
||||
|
||||
<br>
|
||||
|
||||
## Reporting Issues
|
||||
|
||||
If you encounter any issues or have suggestions for improvements, please feel free to (create an issue on our GitHub repository)[https://github.com/twentyhq/twenty/issues/new]. When reporting issues, please provide as much detail as possible to help us understand and address the problem effectively.
|
||||
If you encounter any issues or have suggestions for improvements, please feel free to (create an issue on Twenty's GitHub repository)[https://github.com/twentyhq/twenty/issues/new]. When reporting issues, please provide as much detail as possible to help in understanding and addressing the problem effectively.
|
||||
|
||||
---
|
||||
|
||||
Thank you for considering contributing to Twenty. Your contributions help us make our CRM platform even better!
|
||||
Thank you for considering contributing to Twenty. Your contributions help make Twenty's CRM platform even better!
|
||||
|
||||
|
26
.github/SECURITY.md
vendored
26
.github/SECURITY.md
vendored
@ -2,27 +2,27 @@
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
We strongly encourage reporting any potential vulnerabilities.
|
||||
Reporting any potential vulnerabilities is strongly encouraged.
|
||||
|
||||
If you suspect a vulnerability, please take the following steps:
|
||||
- Contact us immediately at `security at twenty.com`.
|
||||
- Include a comprehensive description of the potential vulnerability and steps to reproduce the issue, if possible. The more information you can provide, the quicker we can address the problem.
|
||||
- Contact the team at `security at twenty.com`.
|
||||
- Include a comprehensive description of the potential vulnerability and steps to reproduce the issue, if possible. The more information you can provide, the quicker Twenty can address the problem.
|
||||
|
||||
Our commitment is to respond to your initial report within one business day.
|
||||
While we're addressing the issue, we kindly request you to maintain confidentiality about the vulnerability to ensure the security of all users.
|
||||
You can expect a response to your initial report within one business day.
|
||||
While the core team works on addressing the issue, please maintain confidentiality about the vulnerability to ensure the security of all users.
|
||||
Please refrain from exploiting the vulnerability or revealing the problem to others.
|
||||
|
||||
While we don't currently have a formal bug bounty program due to the project's nascent stage, we can assure you that:
|
||||
While Twenty doesn't have a formal bug bounty program right now due to the project's nascent stage, rest assured that:
|
||||
|
||||
- Your report will be responded to within one business day.
|
||||
- Your report and all accompanying data will be handled with utmost confidentiality.
|
||||
- We greatly appreciate your contribution and would be happy to acknowledge your role in the vulnerability fix, should you choose to be identified.
|
||||
- We will grant you permission to publicly discuss your findings after the patch has been released and a reasonable time has passed for users to implement it.
|
||||
- We (obviously) guarantee that we will not pursue any legal action as long as the vulnerability is not exploited.
|
||||
- You will get a response within one business day.
|
||||
- Your report and all accompanying data will receive the highest level of confidentiality.
|
||||
- Your contribution is greatly appreciated, and Twenty would acknowledge your role in the vulnerability fix, if you opt for identification.
|
||||
- Twenty will grant you permission to publicly discuss your findings once users have had a reasonable time to apply the patch after it becomes available.
|
||||
- Twenty guarantees not to pursue any legal action as long as the vulnerability is not exploited.
|
||||
|
||||
## Security Features
|
||||
We are always looking for ways to improve our product's security.
|
||||
If you have any recommendations or feature request that could enhance the product's security, we invite you to share them with us via the discussion forum.
|
||||
Efforts are continually made to enhance the security of the product.
|
||||
If you have any recommendations or feature request that could enhance the product's security, please share them via the discussion forum.
|
||||
|
||||
⚠️ Note this does not apply to security vulnerabilities. If you're in doubt, then always follow the security vulnerability process
|
||||
|
||||
|
2
.github/styles/docs/Acronyms.yml
vendored
2
.github/styles/docs/Acronyms.yml
vendored
@ -45,6 +45,7 @@ exceptions:
|
||||
- PDF
|
||||
- PHP
|
||||
- POST
|
||||
- PII
|
||||
- RAM
|
||||
- REPL
|
||||
- RSA
|
||||
@ -58,6 +59,7 @@ exceptions:
|
||||
- TBD
|
||||
- TCP
|
||||
- TODO
|
||||
- TSX
|
||||
- URI
|
||||
- URL
|
||||
- USB
|
||||
|
2
.github/styles/docs/TypeScript.yml
vendored
2
.github/styles/docs/TypeScript.yml
vendored
@ -1,6 +1,6 @@
|
||||
extends: existence
|
||||
message: "Consider using typescript instead of tsx"
|
||||
level: warning
|
||||
level: suggestion
|
||||
scope: raw
|
||||
ignorecase: true
|
||||
raw:
|
||||
|
2
.github/styles/write-good/TooWordy.yml
vendored
2
.github/styles/write-good/TooWordy.yml
vendored
@ -83,7 +83,6 @@ tokens:
|
||||
- exclusively
|
||||
- expedite
|
||||
- expend
|
||||
- expiration
|
||||
- facilitate
|
||||
- factual evidence
|
||||
- feasible
|
||||
@ -208,7 +207,6 @@ tokens:
|
||||
- took advantage of
|
||||
- transmit
|
||||
- transpire
|
||||
- type of
|
||||
- until such time as
|
||||
- utilization
|
||||
- utilize
|
||||
|
1
.github/styles/write-good/Weasel.yml
vendored
1
.github/styles/write-good/Weasel.yml
vendored
@ -124,7 +124,6 @@ tokens:
|
||||
- normally
|
||||
- obediently
|
||||
- occasionally
|
||||
- only
|
||||
- openly
|
||||
- painfully
|
||||
- particularly
|
||||
|
@ -9,15 +9,15 @@ This document outlines the best practices you should follow when working on the
|
||||
|
||||
## State management
|
||||
|
||||
We use React and Recoil for state management.
|
||||
React and Recoil handle state management in the codebase.
|
||||
|
||||
### Use `useRecoilState` to store state
|
||||
|
||||
We recommend that you create as many atoms as you need to store your state.
|
||||
It's good practice to create as many atoms as you need to store your state.
|
||||
|
||||
:::tip
|
||||
|
||||
It's better to use additional atoms than trying to be too concise with props drilling.
|
||||
It's better to use extra atoms than trying to be too concise with props drilling.
|
||||
|
||||
:::
|
||||
|
||||
@ -43,33 +43,33 @@ export const MyComponent = () => {
|
||||
|
||||
### Do not use `useRef` to store state
|
||||
|
||||
We do not recommend using `useRef` to store state.
|
||||
Avoid using `useRef` to store state.
|
||||
|
||||
If you want to store state, you should use `useState` or `useRecoilState`.
|
||||
|
||||
We recommend seeing [how to manage re-renders](#managing-re-renders) if you feel like you need `useRef` to prevent some re-renders from happening.
|
||||
See [how to manage re-renders](#managing-re-renders) if you feel like you need `useRef` to prevent some re-renders from happening.
|
||||
|
||||
## Managing re-renders
|
||||
|
||||
Re-renders can be hard to manage in React.
|
||||
|
||||
We provide you with some rules that we follow to avoid unnecessary re-renders.
|
||||
Here are some rules to follow to avoid unnecessary re-renders.
|
||||
|
||||
Keep in mind that re-renders can **always** be avoided by understanding their cause.
|
||||
Keep in mind that you can **always** avoid re-renders by understanding their cause.
|
||||
|
||||
### Work at the root level
|
||||
|
||||
We made it easy for you to avoid re-renders in new features by taking care of eliminating them at the root level.
|
||||
Avoiding re-renders in new features is now made easy by eliminating them at the root level.
|
||||
|
||||
There's only one `useEffect` in the sidecar component `PageChangeEffect` that holds all the logic that should be executed on a page change.
|
||||
The `PageChangeEffect` sidecar component contains just one `useEffect` that holds all the logic to execute on a page change.
|
||||
|
||||
That way you know that there's only one place that can trigger a re-render.
|
||||
That way you know that there's just one place that can trigger a re-render.
|
||||
|
||||
### Always think twice before adding `useEffect` in your codebase
|
||||
|
||||
Re-renders are often caused by unnecessary `useEffect`.
|
||||
|
||||
You should think whether the `useEffect` is really needed, or if you can move the logic in a event handler function.
|
||||
You should think whether you need `useEffect`, or if you can move the logic in a event handler function.
|
||||
|
||||
You'll find it generally easy to move the logic in a `handleClick` or `handleChange` function.
|
||||
|
||||
@ -79,7 +79,7 @@ You can also find them in libraries like Apollo: `onCompleted`, `onError`, etc.
|
||||
|
||||
If you feel like you need to add a `useEffect` in your root component, you should consider extracting it in a sidecar component.
|
||||
|
||||
The same can be applied for data fetching logic, with Apollo hooks.
|
||||
You can apply the same for data fetching logic, with Apollo hooks.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, will cause re-renders even if data is not changing,
|
||||
@ -138,11 +138,11 @@ export const App = () => (
|
||||
|
||||
Recoil family states and selectors are a great way to avoid re-renders.
|
||||
|
||||
They are especially useful when you need to store a list of items.
|
||||
They are useful when you need to store a list of items.
|
||||
|
||||
### You shouldn't use `React.memo(MyComponent)`
|
||||
|
||||
We do not recommend using `React.memo()` because it does not solve the cause of the re-render, but instead breaks the re-render chain, which can lead to unexpected behavior and make the code really hard to refactor.
|
||||
Avoid using `React.memo()` because it does not solve the cause of the re-render, but instead breaks the re-render chain, which can lead to unexpected behavior and make the code very hard to refactor.
|
||||
|
||||
### Limit `useCallback` or `useMemo` usage
|
||||
|
||||
@ -150,9 +150,9 @@ They are often not necessary and will make the code harder to read and maintain
|
||||
|
||||
## Console.logs
|
||||
|
||||
`console.log` statements are invaluable during development, offering real-time insights into variable values and code flow. However, leaving them in production code can lead to several issues:
|
||||
`console.log` statements are invaluable during development, offering real-time insights into variable values and code flow. But, leaving them in production code can lead to several issues:
|
||||
|
||||
1. **Performance**: Excessive logging can affect the runtime performance, especially on client-side applications.
|
||||
1. **Performance**: Excessive logging can affect the runtime performance, specially on client-side applications.
|
||||
|
||||
2. **Security**: Logging sensitive data can expose critical information to anyone who inspects the browser's console.
|
||||
|
||||
@ -169,7 +169,7 @@ Make sure you remove all `console.logs` before pushing the code to production.
|
||||
Variable names ought to precisely depict the purpose or function of the variable.
|
||||
|
||||
#### The issue with generic names
|
||||
Generic names in programming are not ideal because they lack specificity, leading to ambiguity and reduced code readability. Such names fail to convey the variable or function's purpose, making it challenging for developers to understand the code's intent without deeper investigation. This can result in increased debugging time, higher susceptibility to errors, and difficulties in maintenance and collaboration. Descriptive naming, on the other hand, makes the code self-explanatory and easier to navigate, enhancing overall code quality and developer productivity.
|
||||
Generic names in programming are not ideal because they lack specificity, leading to ambiguity and reduced code readability. Such names fail to convey the variable or function's purpose, making it challenging for developers to understand the code's intent without deeper investigation. This can result in increased debugging time, higher susceptibility to errors, and difficulties in maintenance and collaboration. Meanwhile, descriptive naming makes the code self-explanatory and easier to navigate, enhancing code quality and developer productivity.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, uses a generic name that doesn't communicate its
|
||||
@ -206,11 +206,11 @@ const handleEmailChange = (val: string) => {
|
||||
|
||||
## Optional Props
|
||||
|
||||
Avoid supplying the default value for an optional prop, as it generally doesn’t contribute significantly.
|
||||
Avoid passing the default value for an optional prop.
|
||||
|
||||
**EXAMPLE**
|
||||
|
||||
Assume, we have the `EmailField` component defined below:
|
||||
Take the`EmailField` component defined below:
|
||||
|
||||
```tsx
|
||||
type EmailFieldProps = {
|
||||
@ -223,7 +223,7 @@ const EmailField = ({ value, disabled = false }: EmailFieldProps) => (
|
||||
);
|
||||
```
|
||||
|
||||
**USAGE**
|
||||
**Usage**
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, passing in the same value as the default value adds no value
|
||||
@ -260,13 +260,13 @@ For React to understand that the component is a component, you need to use Pasca
|
||||
|
||||
## Prop Drilling: Keep It Minimal
|
||||
|
||||
Prop drilling, in the React context, refers to the practice of passing state variables and their setters through multiple component layers, even if intermediary components don't use them. While sometimes necessary, excessive prop drilling can lead to:
|
||||
Prop drilling, in the React context, refers to the practice of passing state variables and their setters through many component layers, even if intermediary components don't use them. While sometimes necessary, excessive prop drilling can lead to:
|
||||
|
||||
1. **Decreased Readability**: Tracing where a prop originates or where it's utilized can become convoluted in a deeply nested component structure.
|
||||
|
||||
2. **Maintenance Challenges**: Changes in one component's prop structure might necessitate adjustments in several components, even if they don't directly use the prop.
|
||||
2. **Maintenance Challenges**: Changes in one component's prop structure might require adjustments in several components, even if they don't directly use the prop.
|
||||
|
||||
3. **Reduced Component Reusability**: A component receiving numerous props solely for the purpose of passing them down becomes less general-purpose and harder to reuse in different contexts.
|
||||
3. **Reduced Component Reusability**: A component receiving a lot of props solely for passing them down becomes less general-purpose and harder to reuse in different contexts.
|
||||
|
||||
If you feel that you are using excessive prop drilling, see [state management best practices](/contributor/frontend/advanced/best-practices#state-management).
|
||||
|
||||
@ -274,7 +274,7 @@ If you feel that you are using excessive prop drilling, see [state management be
|
||||
|
||||
When importing, opt for the designated aliases rather than specifying complete or relative paths.
|
||||
|
||||
**THE ALIASES**
|
||||
**The Aliases**
|
||||
|
||||
```js
|
||||
{
|
||||
@ -286,7 +286,7 @@ When importing, opt for the designated aliases rather than specifying complete o
|
||||
}
|
||||
```
|
||||
|
||||
**USAGE**
|
||||
**Usage**
|
||||
```tsx
|
||||
// ❌ Bad, specifies the entire relative path
|
||||
import {
|
||||
@ -305,7 +305,7 @@ import { ComponentDecorator } from '~/testing/decorators/ComponentDecorator';=
|
||||
|
||||
## Schema Validation
|
||||
|
||||
[Zod](https://github.com/colinhacks/zod) is used as the schema validator for untyped objects:
|
||||
[Zod](https://github.com/colinhacks/zod) is the schema validator for untyped objects:
|
||||
|
||||
```js
|
||||
const validationSchema = z
|
||||
@ -326,5 +326,5 @@ type Form = z.infer<typeof validationSchema>;
|
||||
|
||||
## Breaking Changes
|
||||
|
||||
Prioritize thorough manual testing before proceeding to guarantee that modifications haven’t caused disruptions elsewhere, given that tests have not yet been extensively integrated.
|
||||
Always perform thorough manual testing before proceeding to guarantee that modifications haven’t caused disruptions elsewhere, given that tests have not yet been extensively integrated.
|
||||
|
||||
|
@ -7,9 +7,9 @@ sidebar_custom_props:
|
||||
|
||||
You can intercept any hotkey combination and execute a custom action.
|
||||
|
||||
We added a thin wrapper on top of [react-hotkeys-hook](https://react-hotkeys-hook.vercel.app/docs/intro) to make it more performant and to avoid unnecessary re-renders.
|
||||
There's a thin wrapper on top of [react-hotkeys-hook](https://react-hotkeys-hook.vercel.app/docs/intro) that makes it more performant and avoids unnecessary re-renders.
|
||||
|
||||
We also created a wrapper hook `useScopedHotkeys` to make it easy to manage scopes.
|
||||
There's also a wrapper hook `useScopedHotkeys` that makes it easy to manage scopes.
|
||||
|
||||
```ts
|
||||
useScopedHotkeys(
|
||||
|
@ -5,15 +5,15 @@ sidebar_custom_props:
|
||||
icon: TbPencil
|
||||
---
|
||||
|
||||
We define here the rules to follow when writing code.
|
||||
This document includes the rules to follow when writing code.
|
||||
|
||||
Our goal is to have a consistent codebase, which is easy to read and easy to maintain.
|
||||
The goal here is to have a consistent codebase, which is easy to read and easy to maintain.
|
||||
|
||||
For this we prefer being a bit more verbose than being too concise.
|
||||
For this, it's better to be a bit more verbose than to be too concise.
|
||||
|
||||
Always keep in mind that code is read more often than it is written, especially on an open source project, where anyone can contribute.
|
||||
Always keep in mind that people read code more often than they write it, specially on an open source project, where anyone can contribute.
|
||||
|
||||
There are a lot of rules that are not defined here, but that are automatically checked by our linters.
|
||||
There are a lot of rules that are not defined here, but that are automatically checked by linters.
|
||||
|
||||
## React
|
||||
|
||||
@ -55,7 +55,7 @@ type MyComponentProps = {
|
||||
export const MyComponent = ({ name }: MyComponentProps) => <div>Hello {name}</div>;
|
||||
```
|
||||
|
||||
#### Refrain from using `React.FC` or `React.FunctionComponent` to define prop types.
|
||||
#### Refrain from using `React.FC` or `React.FunctionComponent` to define prop types
|
||||
|
||||
```tsx
|
||||
/* ❌ - Bad, defines the component type annotations with `FC`
|
||||
@ -86,7 +86,7 @@ const EmailField = ({ value }: EmailFieldProps) => (
|
||||
|
||||
#### No Single Variable Prop Spreading in JSX Elements
|
||||
|
||||
We discourage the use of single variable prop spreading in JSX elements, like `{...props}`. This practice often leads to less readable and maintainable code as it's unclear what props are being passed down to the component.
|
||||
Avoid using single variable prop spreading in JSX elements, like `{...props}`. This practice often results in code that is less readable and harder to maintain because it's unclear which props the component is receiving.
|
||||
|
||||
```tsx
|
||||
/* ❌ - Bad, spreads a single variable prop into the underlying component
|
||||
@ -106,9 +106,9 @@ const MyComponent = ({ prop1, prop2, prop3 }: MyComponentProps) => {
|
||||
```
|
||||
|
||||
Rationale:
|
||||
- It's clearer to see at a glance which props are being passed down, making the code easier to understand and maintain.
|
||||
- At a glance, it's clearer which props the code passes down, making it easier to understand and maintain.
|
||||
- It helps to prevent tight coupling between components via their props.
|
||||
- It's easier to catch misspelled or unused props with linting tools when props are listed explicitly
|
||||
- Linting tools make it easier to identify misspelled or unused props when you list props explicitly.
|
||||
|
||||
## JavaScript
|
||||
|
||||
@ -136,7 +136,7 @@ onClick?.();
|
||||
|
||||
### Use `type` instead of `interface`
|
||||
|
||||
We decided to always use `type` instead of `interface`, because they almost always overlap, and `type` is more flexible.
|
||||
Always use `type` instead of `interface`, because they almost always overlap, and `type` is more flexible.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad
|
||||
@ -152,7 +152,7 @@ type MyType = {
|
||||
|
||||
### Use string literals instead of enums
|
||||
|
||||
[String literals](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) are the go-to way to handle enum-like values in TypeScript. They are easier to extend with Pick and Omit, and offer a better developer experience, especially with code completion.
|
||||
[String literals](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) are the go-to way to handle enum-like values in TypeScript. They are easier to extend with Pick and Omit, and offer a better developer experience, specially with code completion.
|
||||
|
||||
You can see why TypeScript recommends avoiding enums [here](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums).
|
||||
|
||||
@ -172,11 +172,11 @@ let color = Color.Red;
|
||||
let color: "red" | "green" | "blue" = "red";
|
||||
```
|
||||
|
||||
#### GraphQL and internal libs
|
||||
#### GraphQL and internal libraries
|
||||
|
||||
We recommend using enums that are generated by GraphQL codegen.
|
||||
You should use enums that GraphQL codegen generates.
|
||||
|
||||
We also recommend using an enum when using an internal lib, so the internal lib doesn't have to expose a string literal type that is not related to the internal API.
|
||||
It's also better to use an enum when using an internal library, so the internal library doesn't have to expose a string literal type that is not related to the internal API.
|
||||
|
||||
Example:
|
||||
|
||||
@ -195,7 +195,7 @@ setHotkeyScopeAndMemorizePreviousScope(
|
||||
|
||||
### Use StyledComponents
|
||||
|
||||
Components should be styled with [styled-components](https://emotion.sh/docs/styled).
|
||||
Style the components with [styled-components](https://emotion.sh/docs/styled).
|
||||
|
||||
```tsx
|
||||
// ❌ Bad
|
||||
@ -209,7 +209,7 @@ const StyledTitle = styled.div`
|
||||
`;
|
||||
```
|
||||
|
||||
Styled components should be prefixed with "Styled" to differentiate them from "real" components.
|
||||
Prefix styled components with "Styled" to differentiate them from "real" components.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad
|
||||
@ -235,7 +235,7 @@ Avoid using `px` or `rem` values directly within the styled components. The nece
|
||||
|
||||
#### Colors
|
||||
|
||||
Refrain from introducing additional colors; instead, utilize the existing palette from the theme. Should there be a situation where the palette does not align, kindly leave a comment so that it can be rectified.
|
||||
Refrain from introducing new colors; instead, use the existing palette from the theme. Should there be a situation where the palette does not align, please leave a comment so that the team can rectify it.
|
||||
|
||||
|
||||
```tsx
|
||||
@ -261,7 +261,7 @@ const StyledButton = styled.button`
|
||||
```
|
||||
## Enforcing No-Type Imports
|
||||
|
||||
In our codebase, we've adopted a coding standard to disallow type imports. This helps maintain consistency and readability in our TypeScript code. To enforce this standard, we've added an ESLint rule that checks for and reports any type imports.
|
||||
Avoid type imports. To enforce this standard, an ESLint rule checks for and reports any type imports. This helps maintain consistency and readability in the TypeScript code.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad
|
||||
@ -274,18 +274,18 @@ import type { Meta, StoryObj } from '@storybook/react';
|
||||
import { Meta, StoryObj } from '@storybook/react';
|
||||
```
|
||||
|
||||
### Why No-Type Imports?
|
||||
### Why No-Type Imports
|
||||
|
||||
- **Consistency**: By avoiding type imports, our codebase remains consistent in its module import style. We use a single approach for both type and value imports.
|
||||
- **Consistency**: By avoiding type imports and using a single approach for both type and value imports, the codebase remains consistent in its module import style.
|
||||
|
||||
- **Readability**: No-type imports improve code readability by making it clear when you're importing values or types. This reduces ambiguity and makes it easier to understand the purpose of imported symbols.
|
||||
|
||||
- **Maintainability**: Codebase maintainability is enhanced because developers can quickly identify and locate type-only imports when reviewing or modifying code.
|
||||
- **Maintainability**: It enhances codebase maintainability because developers can identify and locate type-only imports when reviewing or modifying code.
|
||||
|
||||
### ESLint Rule
|
||||
|
||||
We've configured an ESLint rule, `@typescript-eslint/consistent-type-imports`, to enforce the no-type import standard. This rule will generate errors or warnings for any type import violations.
|
||||
An ESLint rule, `@typescript-eslint/consistent-type-imports`, enforces the no-type import standard. This rule will generate errors or warnings for any type import violations.
|
||||
|
||||
Please note that this rule is intended to address rare edge cases where type imports might be used unintentionally. TypeScript itself discourages this practice, as mentioned in the [TypeScript 3.8 release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html). In most situations, you should not need to use type-only imports.
|
||||
Please note that this rule specifically addresses rare edge cases where unintentional type imports occur. TypeScript itself discourages this practice, as mentioned in the [TypeScript 3.8 release notes](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html). In most situations, you should not need to use type-only imports.
|
||||
|
||||
To ensure your code complies with this rule, make sure to run ESLint as part of your development workflow.
|
||||
|
@ -9,7 +9,7 @@ import DocCardList from '@theme/DocCardList';
|
||||
|
||||
## Tech Stack
|
||||
|
||||
We took care of having a clean and simple stack, with minimal boilerplate code.
|
||||
The project has a clean and simple stack, with minimal boilerplate code.
|
||||
|
||||
**App**
|
||||
|
||||
@ -34,20 +34,20 @@ We took care of having a clean and simple stack, with minimal boilerplate code.
|
||||
|
||||
### Routing
|
||||
|
||||
We use [React Router](https://reactrouter.com/) for routing.
|
||||
[React Router](https://reactrouter.com/) handles the routing.
|
||||
|
||||
To avoid unnecessary [re-renders](/contributor/frontend/advanced/best-practices#managing-re-renders) we handle all the routing logic in a `useEffect` in `PageChangeEffect`.
|
||||
To avoid unnecessary [re-renders](/contributor/frontend/advanced/best-practices#managing-re-renders) all the routing logic is in a `useEffect` in `PageChangeEffect`.
|
||||
|
||||
### State Management
|
||||
|
||||
We use [Recoil](https://recoiljs.org/docs/introduction/core-concepts) for state management.
|
||||
[Recoil](https://recoiljs.org/docs/introduction/core-concepts) handles state management.
|
||||
|
||||
See our [best practices](/contributor/frontend/advanced/best-practices#state-management) for more information on state management.
|
||||
See [best practices](/contributor/frontend/advanced/best-practices#state-management) for more information on state management.
|
||||
|
||||
## Testing
|
||||
|
||||
We use [Jest](https://jestjs.io/) for unit testing and [Storybook](https://storybook.js.org/) for component testing.
|
||||
[Jest](https://jestjs.io/) serves as the tool for unit testing while [Storybook](https://storybook.js.org/) is for component testing.
|
||||
|
||||
Jest is mainly used for testing utility functions, and not components themselves.
|
||||
Jest is mainly for testing utility functions, and not components themselves.
|
||||
|
||||
Storybook is used for testing the behavior of isolated components, as well as displaying our [design system](/contributor/frontend/basics/design-system).
|
||||
Storybook is for testing the behavior of isolated components, as well as displaying the [design system](/contributor/frontend/basics/design-system).
|
||||
|
@ -6,5 +6,5 @@ sidebar_custom_props:
|
||||
icon: TbPaint
|
||||
---
|
||||
|
||||
We rely on our internal and custom design system, that is built on top of styled-components.
|
||||
The CRM depends on its internal and custom design system, constructed on top of styled-components.
|
||||
|
||||
|
@ -8,7 +8,7 @@ sidebar_custom_props:
|
||||
|
||||
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 is easier to find the files related to specific features and ensure that the application is scalable and maintainable.
|
||||
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
|
||||
@ -27,12 +27,12 @@ front
|
||||
|
||||
## Pages
|
||||
|
||||
Contains the top-level components that are defined by the application routes. They import more low-level components from the modules folder (more details below).
|
||||
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; we often refer to them as submodules but the same rules apply.
|
||||
They should all follow the structure below. You can nest modules within modules (referred to as submodules) and the same rules will apply.
|
||||
|
||||
```
|
||||
module1
|
||||
@ -67,7 +67,7 @@ See [GraphQL](https://graphql.org/learn/) for more details.
|
||||
|
||||
- Fragments
|
||||
|
||||
A fragment is a reusable piece of a query, which can be used in multiple places. By using fragments, it is easier to avoid duplicating code.
|
||||
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.
|
||||
|
||||
@ -85,24 +85,24 @@ See [Hooks](https://react.dev/learn/reusing-logic-with-custom-hooks) for more de
|
||||
|
||||
### States
|
||||
|
||||
Contains the state management logic. We use [RecoilJS](https://recoiljs.org) for this.
|
||||
Contains the state management logic. [RecoilJS](https://recoiljs.org) handles this.
|
||||
|
||||
- Selectors: See [RecoilJS Selectors](https://recoiljs.org/docs/basic-tutorial/selectors) for more details.
|
||||
|
||||
We still use React's built-in state management for state that is only used within a component.
|
||||
React's built-in state management still handles state within a component.
|
||||
|
||||
### Utils
|
||||
|
||||
Should only contain reusable pure functions. Otherwise, create custom hooks in the `hooks` folder.
|
||||
Should just contain reusable pure functions. Otherwise, create custom hooks in the `hooks` folder.
|
||||
|
||||
|
||||
## UI
|
||||
|
||||
Contains all of the reusable UI components used in the application.
|
||||
Contains all the reusable UI components used in the application.
|
||||
|
||||
This folder can contain subfolders, like `data`, `display`, `feedback`, and `input` for specific types of components. Each component should be self-contained and reusable, so that it can be used in multiple parts of 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 is easier to maintain a consistent design and to make changes to the UI without affecting other parts (business logic) of the codebase.
|
||||
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
|
||||
|
||||
@ -110,4 +110,4 @@ You can import other module code from any module except for the `ui` folder. Thi
|
||||
|
||||
### Internal
|
||||
|
||||
Each part (hooks, states, ...) of a module can have an `internal` folder, which contains parts that are only used within the module.
|
||||
Each part (hooks, states, ...) of a module can have an `internal` folder, which contains parts that are just used within the module.
|
||||
|
@ -7,12 +7,12 @@ sidebar_custom_props:
|
||||
---
|
||||
|
||||
Figma is a collaborative interface design tool that aids in bridging the communication barrier between designers and developers.
|
||||
In this guide, we'll go over how to collaborate with Twenty’s Figma.
|
||||
This guide explains how you can collaborate with Figma.
|
||||
|
||||
## Access
|
||||
|
||||
1. **Access the shared link:** You can access the Twenty Figma file [here](https://www.figma.com/file/xt8O9mFeLl46C5InWwoMrN/Twenty).
|
||||
2. **Sign in:** If you're not already signed in to Figma, you'll be prompted to do so.
|
||||
1. **Access the shared link:** You can access the project's Figma file [here](https://www.figma.com/file/xt8O9mFeLl46C5InWwoMrN/Twenty).
|
||||
2. **Sign in:** If you're not already signed in, Figma will prompt you to do so.
|
||||
Key features are only available to logged-in users, such as the developer mode and the ability to select a dedicated frame.
|
||||
|
||||
:::caution Note
|
||||
@ -24,15 +24,15 @@ You will not be able to collaborate effectively without an account.
|
||||
|
||||
## Figma structure
|
||||
|
||||
On the left sidebar, you can access the different pages of our Figma. They are organised as such:
|
||||
On the left sidebar, you can access the different pages of Twenty's Figma. This is how they're organized:
|
||||
|
||||
- **Components page:** This is the first page. The designer uses it to create and organize the reusable design elements that are used throughout the design file. For example, buttons, icons, symbols, or any other reusable components. It serves to maintain consistency across the design.
|
||||
- **Main page:** The second page is the main page, where the complete user interface of the project is shown. You can press ***Play*** to use the full app prototype.
|
||||
- **Features pages:** The subsequent pages are typically dedicated to features being worked on. They contain the design of specific features or modules of the application or website. They are usually still being worked on.
|
||||
- **Components page:** This is the first page. The designer uses it to create and organize the reusable design elements used throughout the design file. For example, buttons, icons, symbols, or any other reusable components. It serves to maintain consistency across the design.
|
||||
- **Main page:** The second page is the main page, which shows the complete user interface of the project. You can press ***Play*** to use the full app prototype.
|
||||
- **Features pages:** The other pages are typically dedicated to features in progress. They contain the design of specific features or modules of the application or website. They are typically still in progress.
|
||||
|
||||
## Useful Tips
|
||||
|
||||
With read-only access, you can't edit the design but you can access all features that will be useful to implement the designs into code.
|
||||
With read-only access, you can't edit the design but you can access all features that will be useful to convert the designs into code.
|
||||
|
||||
### Use the Dev mode
|
||||
|
||||
@ -44,8 +44,8 @@ Switch to the "Developer" mode in the right part of the toolbar to see design sp
|
||||
|
||||
Click on any element on the canvas and press the “Play” button at the top right edge of the interface to access the prototype view. Prototype mode allows you to interact with the design as if it were the final product. It demonstrates the flow between screens and how interface elements like buttons, links, or menus behave when interacted with.
|
||||
|
||||
1. **Understanding transitions and animations:** In the Prototype mode, any transitions or animations added by a designer between screens or UI elements can be viewed, providing clear visual instructions to developers on the intended behavior and style.
|
||||
2. **Implementation clarification:** A prototype can also be used to reduce ambiguities. Developers can interact with it to gain a better understanding of the functionality or appearance of particular elements.
|
||||
1. **Understanding transitions and animations:** In the Prototype mode, you can view any transitions or animations added by a designer between screens or UI elements, providing clear visual instructions to developers on the intended behavior and style.
|
||||
2. **Implementation clarification:** A prototype can also help reduce ambiguities. Developers can interact with it to gain a better understanding of the functionality or appearance of particular elements.
|
||||
|
||||
For more comprehensive details and guidance on learning the Figma platform, you can visit the official [Figma Documentation](https://help.figma.com/hc/en-us).
|
||||
|
||||
@ -57,7 +57,7 @@ Select an element, hold `Option` key (Mac) or `Alt` key (Windows), then hover ov
|
||||
|
||||
[Figma for VS Code](https://marketplace.visualstudio.com/items?itemName=figma.figma-vscode-extension)
|
||||
lets you navigate and inspect design files, collaborate with designers, track changes, and speed up implementation - all without leaving your text editor.
|
||||
It is part of our recommended extensions.
|
||||
It's part of our recommended extensions.
|
||||
|
||||
## Collaboration
|
||||
|
||||
|
@ -8,6 +8,6 @@ sidebar_custom_props:
|
||||
---
|
||||
|
||||
Welcome to the Frontend Development section of the documentation.
|
||||
Here you will find information about the frontend development process, the tools we use, and the best practices we follow.
|
||||
Here you will find information about the frontend development process, the recommended tools, and the best practices you should follow.
|
||||
|
||||
|
||||
|
@ -9,14 +9,14 @@ sidebar_custom_props:
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This guide will walk you through provisioning the project with Docker. This comes with a few advantages:
|
||||
- It provides the exact same environment as our core developer team.
|
||||
- It includes some additional dependencies (such as `playwright`) that you might need if you wish to contribute to some advanced areas of the project.
|
||||
This guide will walk you through provisioning the project with Docker. This comes with the following advantages:
|
||||
- It provides the exact same environment as the core development team.
|
||||
- It includes some extra dependencies (such as `playwright`) that you might need if you wish to contribute to some advanced areas of the project.
|
||||
- It provisions a PostgreSQL database.
|
||||
|
||||
:::info
|
||||
We do not recommend setting up the project with Docker if you are a Windows (WSL) user, unless you have experience with it, as it will make troubleshooting harder.
|
||||
If you are a Windows user, we recommend using the [yarn installation](/contributor/local-setup/yarn-setup).
|
||||
Avoid setting up the project with Docker if you are a Windows (WSL) user, unless you have experience with it, as it will make troubleshooting harder.
|
||||
If you are a Windows user, it's better to use the [yarn installation](/contributor/local-setup/yarn-setup).
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
@ -31,7 +31,7 @@ In your terminal, run the following command:
|
||||
|
||||
:::info Note
|
||||
|
||||
We recommend using SSH for this step. If you already haven't set up SSH keys, please do so first. You can learn more about it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh).
|
||||
It's better to use SSH for this step. If you already haven't set up SSH keys, please do so first. You can learn more about it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh).
|
||||
|
||||
:::
|
||||
|
||||
@ -51,9 +51,9 @@ git clone https://github.com/twentyhq/twenty.git
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Step 2: Setup env variables
|
||||
## Step 2: Setup environment variables
|
||||
|
||||
Twenty requires a few environment variables to be set. Locally, we recommend setting them through `.env` files.
|
||||
You need to set some environment variables before you can work on the project. Locally, it's better to set them through `.env` files.
|
||||
|
||||
```bash
|
||||
cd twenty
|
||||
@ -72,12 +72,12 @@ PG_DATABASE_URL=postgres://twenty:twenty@postgres:5432/default?connection_limit=
|
||||
|
||||
## Step 3: Build
|
||||
|
||||
We provide an environment containerized with Docker and orchestrated with `docker-compose`.
|
||||
The project includes an environment containerized with Docker and orchestrated with `docker-compose`.
|
||||
This installation method will also provision a PostgreSQL container.
|
||||
|
||||
:::info
|
||||
|
||||
The configuration for the build is stored in the `infra/dev` folder, but you can run `make` commands directly from the root folder.
|
||||
The configuration for the build is in the `infra/dev` folder, but you can run `make` commands directly from the root folder.
|
||||
|
||||
:::
|
||||
|
||||
@ -116,7 +116,7 @@ You should now have:
|
||||
- **Server** available on: [http://localhost:3000/graphql](http://localhost:3000/graphql)
|
||||
- **Postgres** available on [http://localhost:5432](http://localhost:5432) and containing database named `default`
|
||||
|
||||
Sign in using our seeded demo account `tim@apple.dev` (password: `Applecar2025`) to start using Twenty.
|
||||
Sign in using a seeded demo account `tim@apple.dev` (password: `Applecar2025`) to start using Twenty.
|
||||
|
||||
### Optional
|
||||
|
||||
@ -137,4 +137,4 @@ yarn database:init
|
||||
#### Docker throws errors while setting up local environment
|
||||
|
||||
If by any chance you run into problems with Docker, you should change the `docker-compose` to `docker compose` in `./infra/dev/Makefile` as `docker-compose` is an old version
|
||||
that's becoming slowly obsolete. (More info can be found [here](https://docs.docker.com/compose/migrate/))
|
||||
that's becoming obsolete. (You can find more info [here](https://docs.docker.com/compose/migrate/))
|
||||
|
@ -6,12 +6,12 @@ sidebar_custom_props:
|
||||
icon: TbBrandVscode
|
||||
---
|
||||
|
||||
This section will help you set up your IDE for the project. If you haven't set up your development environment, please refer to our [local setup](/contributor/local-setup) section.
|
||||
This section will help you set up your IDE for the project. If you haven't set up your development environment, please refer to the [local setup](/contributor/local-setup) section.
|
||||
|
||||
|
||||
## Visual Studio Code
|
||||
|
||||
You can use any IDE you want but we recommend using Visual Studio Code as our internal team uses it and we have a lot of extensions and settings that we can share with you.
|
||||
You can use any IDE you prefer, but Visual Studio Code is the choice of the core team, and has lots of extensions and settings to share with you.
|
||||
|
||||
|
||||
### Step 1: Installation
|
||||
@ -20,7 +20,7 @@ You can download Visual Studio Code from [here](https://code.visualstudio.com/do
|
||||
|
||||
### Step 2: Open Project
|
||||
|
||||
Once you have installed Visual Studio Code, you can open the project by clicking on `File > Open Folder` and selecting `twenty` project root folder.
|
||||
Once you install Visual Studio Code, you can open the project by clicking on `File > Open Folder` and selecting `twenty` project root folder.
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/img/contributor/ide-project-open.png" alt="Visual Studio Code: Open Twenty project" width="90%" />
|
||||
@ -44,11 +44,11 @@ If you are using a [Docker setup](/contributor/local-setup/docker-setup), you wi
|
||||
</div>
|
||||
|
||||
<br />
|
||||
VSCode will open a new window and you will be able to use it as you would normally do. The only difference is that you will be running VSCode inside the container and you will have access to all the tools and dependencies that are installed in the container.
|
||||
VSCode will open a new window and you will be able to use it as you would typically do. The only difference is that you will be running VSCode inside the container and you will have access to all the tools and dependencies installed in the container.
|
||||
|
||||
<br /><br />
|
||||
If you stop your containers, you will need to restart them before opening the project in VSCode again.
|
||||
|
||||
## You are all set
|
||||
|
||||
You are all set to start contributing to the project. If you have any questions, feel free to reach out to us on [Discord](https://twenty.com/discord).
|
||||
You are all set to start contributing to the project. If you have any questions, feel free to reach out to the team on [Discord](https://twenty.com/discord).
|
@ -11,26 +11,26 @@ import DocCardList from '@theme/DocCardList';
|
||||
|
||||
|
||||
|
||||
Twenty is designed to be developer-friendly, and your local installation should be up and running in a few minutes.
|
||||
Twenty aims for developer-friendliness, and your local installation should be up and running in just a bit.
|
||||
|
||||
<DocCardList/>
|
||||
|
||||
## Discord
|
||||
|
||||
If you have any questions or need help, you can join our [Discord](https://twenty.com/discord) server.
|
||||
If you have any questions or need help, you can join Twenty's [Discord](https://twenty.com/discord) server.
|
||||
|
||||
## MacOS and Linux users
|
||||
|
||||
We recommend using [yarn installation](/contributor/local-setup/yarn-setup) as this is the easiest way to get started.
|
||||
We also provide an easy way to run the project with [Docker](/contributor/local-setup/docker-setup) that you can use if you are familiar with containerized environments.
|
||||
It's better to use [yarn installation](/contributor/local-setup/yarn-setup) as this is the easiest way to get started.
|
||||
But there's also an easy way to run the project with [Docker](/contributor/local-setup/docker-setup) that you can use if you are familiar with containerized environments.
|
||||
|
||||
## Windows users
|
||||
|
||||
Windows users can install the project through WSL2. We provide a [guide](/contributor/local-setup/yarn-setup) to help you get started.
|
||||
Windows users can install the project through WSL2. [This guide](/contributor/local-setup/yarn-setup) can help you get started.
|
||||
|
||||
## Project structure
|
||||
|
||||
The repository is structured as follows:
|
||||
The repository has the following structure:
|
||||
```
|
||||
twenty
|
||||
└───docs // contains this documentation
|
||||
|
@ -9,22 +9,22 @@ sidebar_custom_props:
|
||||
|
||||
## CR line breaks found [Windows]
|
||||
|
||||
This is due to the linebreak characters of Windows and the git configuration. Try running:
|
||||
This is due to the line break characters of Windows and the git configuration. Try running:
|
||||
```
|
||||
git config --global core.autocrlf false
|
||||
```
|
||||
|
||||
Then delete the repository and clone it again.
|
||||
|
||||
## Extra yarn files are created
|
||||
## Extra yarn files
|
||||
|
||||
If you have extra files created by yarn (`yarn.lock`, `.yarnrc.yml`, `.yarn`), you may have a yarn version issue.
|
||||
Try installing [yarn classic](https://classic.yarnpkg.com/lang/en/)!
|
||||
|
||||
## Missing metadata schema
|
||||
|
||||
During Twenty installation, your postgres database needs to be provisioned with right schemas, extensions, and users.
|
||||
We provide [different ways](/contributor/local-setup/yarn-setup#step-2-set-up-postgresql-database) to set up your postgres instance.
|
||||
During Twenty installation, you need to provision your postgres database with the right schemas, extensions, and users.
|
||||
This documentation includes [different ways](/contributor/local-setup/yarn-setup#step-2-set-up-postgresql-database) to set up your postgres instance.
|
||||
|
||||
If you successfully run this provisioning, you should have `default` and `metadata` schemas in your database.
|
||||
If you don't, make sure you don't have multiple postgres instance running on your computer.
|
||||
If you're successful in running this provisioning, you should have `default` and `metadata` schemas in your database.
|
||||
If you don't, make sure you don't have more than one postgres instance running on your computer.
|
||||
|
@ -9,10 +9,10 @@ sidebar_custom_props:
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
In this document, you'll learn how to install the project using yarn. We recommend this method since it's the easiest way to get started but you can also run the project with [Docker](/contributor/local-setup/docker-setup).
|
||||
In this document, you'll learn how to install the project using yarn. You should use this method since it's the easiest way to get started but you can also run the project with [Docker](/contributor/local-setup/docker-setup).
|
||||
|
||||
:::info
|
||||
`npm` currently does not support local packages satisfactorily. We strongly recommend using `yarn` instead.
|
||||
`npm` does not support local packages well, opt for `yarn` instead.
|
||||
:::
|
||||
|
||||
## Prerequisites
|
||||
@ -36,10 +36,10 @@ Open PowerShell as Administrator and run:
|
||||
```powershell
|
||||
wsl --install
|
||||
```
|
||||
You should be prompted to restart your computer. If not, restart it manually.
|
||||
You should now see a prompt to restart your computer. If not, restart it manually.
|
||||
|
||||
Upon restart, a powershell window will open and install Ubuntu. This may take a few minutes.
|
||||
You will be prompted to create a username and password for your Ubuntu installation.
|
||||
Upon restart, a powershell window will open and install Ubuntu. This may take up some time.
|
||||
You'll see a prompt to create a username and password for your Ubuntu installation.
|
||||
|
||||
2. Install and configure git
|
||||
|
||||
@ -59,7 +59,7 @@ Close and reopen your terminal to start using nvm.
|
||||
|
||||
:::caution Note
|
||||
|
||||
We don't recommend using Docker on WSL as it adds an extra layer of complexity.
|
||||
Avoid using Docker on WSL as it adds an extra layer of complexity.
|
||||
|
||||
:::
|
||||
|
||||
@ -74,7 +74,7 @@ In your terminal, run the following command.
|
||||
|
||||
:::info Note
|
||||
|
||||
We recommend using SSH for this step. If you already haven't set up SSH keys, please do so first. You can learn more about it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh).
|
||||
It's better to use SSH for this step. If you already haven't set up SSH keys, please do so first. You can learn more about it [here](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh).
|
||||
|
||||
:::
|
||||
|
||||
@ -97,7 +97,7 @@ git clone https://github.com/twentyhq/twenty.git
|
||||
|
||||
## Step 2: Set up PostgreSQL Database
|
||||
You need to have a PostgreSQL instance available to be able to use Twenty.
|
||||
This database needs to be provisioned with a `twenty` user (password: `twenty`), a `default` database and a `test` database.
|
||||
You need to provision this database with a `twenty` user (password: `twenty`), a `default` database and a `test` database.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="linux" label="Linux" default>
|
||||
@ -109,7 +109,7 @@ cd twenty
|
||||
./infra/dev/scripts/setup-postgres-linux.sh
|
||||
```
|
||||
|
||||
<b>Option 2:</b> Alternatively if you have docker installed:
|
||||
<b>Option 2:</b> If you have docker installed:
|
||||
<br /><br />
|
||||
|
||||
```bash
|
||||
@ -129,7 +129,7 @@ cd twenty
|
||||
./infra/dev/scripts/setup-postgres-macos.sh
|
||||
```
|
||||
|
||||
<b>Option 2:</b> Alternatively if you have docker installed:
|
||||
<b>Option 2:</b> If you have docker installed:
|
||||
<br /><br />
|
||||
|
||||
```bash
|
||||
@ -142,7 +142,7 @@ You can access this using `twenty` postgres user (password: `twenty`)
|
||||
</TabItem>
|
||||
<TabItem value="wsl" label="Windows (WSL)">
|
||||
|
||||
We recommend that you provision your database locally:
|
||||
It's better to provision your database locally:
|
||||
```bash
|
||||
cd twenty
|
||||
bash ./infra/dev/scripts/setup-postgres-linux.sh
|
||||
@ -153,9 +153,9 @@ You can access this using `twenty` postgres user (password: `twenty`)
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Step 3: Setup env variables
|
||||
## Step 3: Setup environment variables
|
||||
|
||||
Twenty requires a few environment variables to be set. Locally, we recommend setting them through a `.env` file.
|
||||
Twenty requires you to set some environment variables. Locally, you should set them through a `.env` file.
|
||||
|
||||
To do so, make copies of the `.env.example` files in `/front` and `/server`:
|
||||
```bash
|
||||
@ -167,7 +167,7 @@ cp ./server/.env.example ./server/.env
|
||||
|
||||
:::info
|
||||
|
||||
We recommend that you use `nvm` to install the correct `node` version. We have added a `server/.nvmrc` to ensure all contributors use the same version.
|
||||
Use `nvm` to install the correct `node` version. The `server/.nvmrc` ensures all contributors use the same version.
|
||||
|
||||
:::
|
||||
|
||||
@ -187,7 +187,7 @@ Twenty's server will be up and running at [http://localhost:3000/graphql](http:/
|
||||
|
||||
:::info
|
||||
|
||||
For the frontend setup, too, we recommend using `nvm` to install the right node version.
|
||||
For the frontend setup, too, it's better to use `nvm` to install the right node version.
|
||||
|
||||
:::
|
||||
|
||||
@ -201,5 +201,5 @@ yarn
|
||||
yarn start
|
||||
```
|
||||
|
||||
Twenty's frontend will be running at [http://localhost:3001](http://localhost:3001). Simply login using our seeded demo account: `tim@apple.dev` to start using Twenty.
|
||||
Twenty's frontend will be running at [http://localhost:3001](http://localhost:3001). Just login using the seeded demo account: `tim@apple.dev` to start using Twenty.
|
||||
|
||||
|
@ -7,7 +7,7 @@ sidebar_custom_props:
|
||||
|
||||
Objects are structures that allow you to store data (records, attributes, and values) specific to an organization. Twenty provides both standard and custom objects.
|
||||
|
||||
Standard objects are built-in objects with a set of attributes available for all users. Examples of standard objects in Twenty include Company and Person. Standard objects have standard fields that are also available for all Twenty users, like Company.displayName.
|
||||
Standard objects are in-built objects with a set of attributes available for all users. Examples of standard objects in Twenty include Company and Person. Standard objects have standard fields that are also available for all Twenty users, like Company.displayName.
|
||||
|
||||
Custom objects are objects that you can create to store information that is unique to your organization. They are not built-in; members of your workspace can create and customize custom objects to hold information that standard objects aren't suitable for.
|
||||
|
||||
@ -22,21 +22,20 @@ Custom objects are objects that you can create to store information that is uniq
|
||||
|
||||
## How it works
|
||||
|
||||
Custom objects are derived from metadata tables that determine the shape, name, and type of the objects. All this information is stored in the metadata schema database, consisting of tables:
|
||||
Custom objects come from metadata tables that determine the shape, name, and type of the objects. All this information is present in the metadata schema database, consisting of tables:
|
||||
|
||||
- **DataSource**: Details where data is stored.
|
||||
- **Object**: Describes the object and is linked to a DataSource.
|
||||
- **DataSource**: Details where the data is present.
|
||||
- **Object**: Describes the object and links to a DataSource.
|
||||
- **Field**: Outlines an Object's fields and connects to the Object.
|
||||
|
||||
To add a custom object, the workspaceMember will query the /metadata API. Then, the metadata is updated accordingly and a GraphQL schema is computed based on metadata and stored in a GQL cache for later use.
|
||||
|
||||
To add a custom object, the workspaceMember will query the /metadata API. This updates the metadata accordingly and computes a GraphQL schema based on the metadata, storing it in a GQL cache for later use.
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/img/contributor/add-custom-objects.jpeg" alt="Query the /metadata API to add custom objects" />
|
||||
</div>
|
||||
|
||||
<br/>
|
||||
|
||||
To fetch data, querying is done through the /graphql endpoint and goes through the Query Resolver.
|
||||
To fetch data, the process involves making queries through the /graphql endpoint and passing them through the Query Resolver.
|
||||
<div style={{textAlign: 'center'}}>
|
||||
<img src="/img/contributor/custom-objects-schema.png" alt="Query the /graphql endpoint to fetch data" />
|
||||
</div>
|
||||
|
@ -7,7 +7,7 @@ sidebar_custom_props:
|
||||
---
|
||||
|
||||
|
||||
Our backend directory structure is as follows:
|
||||
The backend directory structure is as follows:
|
||||
|
||||
```
|
||||
server
|
||||
@ -45,7 +45,7 @@ See [guards](https://docs.nestjs.com/guards) for more details.
|
||||
|
||||
## Health
|
||||
|
||||
Includes a publicly available REST API (healthz) that returns a JSON to indicate if the database is working as it should.
|
||||
Includes a publicly available REST API (healthz) that returns a JSON to confirm whether the database is working as expected.
|
||||
|
||||
## Metadata
|
||||
|
||||
|
@ -5,7 +5,11 @@ sidebar_custom_props:
|
||||
icon: TbEyeglass
|
||||
---
|
||||
|
||||
We primarily use NestJS for our backend. We previously used to have Prisma as the ORM with a lot of auto-generated code under the hood. But since we want to offer flexibility so that users can create custom fields and custom objects, we needed something more low-level than Prisma to have more fine-grained control. This is why we switched to TypeORM. Here's what our tech stack now looks like.
|
||||
Twenty primarily uses NestJS for the backend.
|
||||
|
||||
Prisma was the first choice as the ORM with a lot of auto-generated code under the hood. But to offer users flexibility and allow them to create custom fields and custom objects, something more low-level than Prisma made more sense to have more fine-grained control. This is why the project now uses TypeORM.
|
||||
|
||||
Here's what the tech stack now looks like.
|
||||
|
||||
## Tech Stack
|
||||
|
||||
|
@ -9,18 +9,17 @@ This document outlines the best practices you should follow when working on the
|
||||
|
||||
## Follow a modular approach
|
||||
|
||||
We follow a modular approach for our backend, which is a fundamental principle when working with NestJS. Make sure you break down your code into reusable modules to maintain a clean and organized codebase.
|
||||
The backend follows a modular approach, which is a fundamental principle when working with NestJS. Make sure you break down your code into reusable modules to maintain a clean and organized codebase.
|
||||
Each module should encapsulate a particular feature or functionality and have a well-defined scope. This modular approach enables clear separation of concerns and removes unnecessary complexities.
|
||||
|
||||
## Expose services to use in modules
|
||||
|
||||
## Expose services to be used in modules
|
||||
Always create services that have a clear and single responsibility, which enhances code readability and maintainability. Name the services descriptively and consistently.
|
||||
|
||||
We encourage creating services that have a clear and single responsibility, which enhances code readability and maintainability. Services should be named descriptively and consistently.
|
||||
|
||||
We also encourage exposing services to be used in other modules. Exposing services to other modules is made possible through NestJS's powerful dependency injection system, and promotes loose coupling between components.
|
||||
You should also expose services that you want to use in other modules. Exposing services to other modules is possible through NestJS's powerful dependency injection system, and promotes loose coupling between components.
|
||||
|
||||
## Avoid using `any` type
|
||||
|
||||
When you declare a variable as `any`, TypeScript's type checker doesn't perform any type checking, making it possible to assign any type of values to the variable. TypeScript is designed to use type inference to determine the type of variable based on the value. By declaring it as `any`, TypeScript can no longer infer the type. This makes it hard to catch type-related errors during development, leading to runtime errors and makes the code less maintainable, less reliable, and harder to understand for others.
|
||||
When you declare a variable as `any`, TypeScript's type checker doesn't perform any type checking, making it possible to assign any type of values to the variable. TypeScript uses type inference to determine the type of variable based on the value. By declaring it as `any`, TypeScript can no longer infer the type. This makes it hard to catch type-related errors during development, leading to runtime errors and makes the code less maintainable, less reliable, and harder to understand for others.
|
||||
|
||||
This is why everything should be typed. So if you create a new object with a first name and last name, you should create an interface or type that contains a first name and last name that defines the shape of the object you are manipulating.
|
||||
This is why everything should have a type. So if you create a new object with a first name and last name, you should create an interface or type that contains a first name and last name that defines the shape of the object you are manipulating.
|
@ -7,9 +7,9 @@ sidebar_custom_props:
|
||||
|
||||
Effortlessly sync Twenty with 3000+ apps using [Zapier](https://zapier.com/). Automate tasks, boost productivity, and supercharge your customer relationships!
|
||||
|
||||
## What is Zapier?
|
||||
## About Zapier
|
||||
|
||||
Zapier is a tool that allows you automate workflows by connecting the apps that your team uses everyday. The fundamental concept of Zapier is automation workflows, which are known as Zaps, and include triggers and actions.
|
||||
Zapier is a tool that allows you automate workflows by connecting the apps that your team uses everyday. The fundamental concept of Zapier is automation workflows, called Zaps, and include triggers and actions.
|
||||
|
||||
You can learn more about how Zapier works [here](https://zapier.com/how-it-works).
|
||||
|
||||
|
@ -9,4 +9,4 @@ sidebar_custom_props:
|
||||
|
||||
Welcome to the Backend Development section of the documentation.
|
||||
|
||||
Here you will find information about the development process, the tools we use, and the best practices we follow.
|
||||
Here you will find information about the development process, the recommended tools, and the best practices you should follow.
|
@ -5,21 +5,21 @@ sidebar_custom_props:
|
||||
icon: TbBrandGraphql
|
||||
---
|
||||
|
||||
Use our [in-browser GraphiQL app](https://docs.twenty.com/graphql/) to browse, query, and mutate our introspection query.
|
||||
Use the [in-browser GraphiQL app](https://docs.twenty.com/graphql/) to browse, query, and mutate the introspection query.
|
||||
|
||||
## What is GraphQL?
|
||||
|
||||
GraphQL is a query language for APIs that enables declarative data fetching that allows a client to specify exactly what data it needs from the API.
|
||||
GraphQL is a query language for APIs that enables declarative data fetching that allows a client to specify the exact data it needs from the API.
|
||||
|
||||
Instead of exposing various endpoints that return fixed data structures, GraphQL exposes only a single endpoint that precisely returns the data that the client asked for. This makes GraphQL more flexible and efficient than other kinds of APIs, like REST APIs.
|
||||
|
||||
To learn more about GraphQL, we recommend going through this [Introduction](https://www.howtographql.com/basics/0-introduction/).
|
||||
You can learn more about GraphQL by going through this [Introduction](https://www.howtographql.com/basics/0-introduction/).
|
||||
|
||||
## About GraphQL Introspection
|
||||
|
||||
GraphQL query language is strongly typed, which makes it possible for you to query and understand the underlying schema.
|
||||
|
||||
With the Introspection feature, you can query the schema and discover the queries (to request data), mutations (to modify data), types, and fields available in a particular GraphQL API.
|
||||
With the Introspection feature, you can query the schema and discover the queries (to request data), mutations (to update data), types, and fields available in a particular GraphQL API.
|
||||
|
||||
## Try Our GraphQL Playground
|
||||
Use our browser-based, interactive [GraphQL playground](https://docs.twenty.com/graphql/) to run mutations and queries to discover valid fields and where you can use them.
|
||||
## Try the GraphQL Playground
|
||||
You can use the browser-based, interactive [GraphQL playground](https://docs.twenty.com/graphql/) to run mutations and queries to discover valid fields and where you can use them.
|
||||
|
@ -7,14 +7,14 @@ custom_edit_url: null
|
||||
---
|
||||
import ThemedImage from '@theme/ThemedImage';
|
||||
|
||||
Twenty is an Open Source CRM that provides flexibility, tailored to your business needs. It helps you break free from vendor lock-in and limitations, and provides the tools needed to harness the full potential of your data while ensuring a sleek and effortlessly intuitive design that teams will love to use.
|
||||
Twenty is an Open Source CRM that provides flexibility, tailored to your business needs. It helps you break free from vendor lock-in and limitations, and provides the tools you need to harness the full potential of your data while ensuring a sleek and effortlessly intuitive design that teams will love to use.
|
||||
<ThemedImage sources={{light: "../img/light-doc-preview.png", dark:"../img/dark-doc-preview.png"}} style={{width:'100%', maxWidth:'800px'}}/>
|
||||
|
||||
|
||||
## Why did we create Twenty?
|
||||
## Idea Behind Twenty
|
||||
We’ve spent thousands of hours grappling with traditional CRMs like Pipedrive and Salesforce to align them with our business needs, only to end up frustrated—customizations are complex and the closed ecosystems of these platforms can feel restrictive.
|
||||
|
||||
We felt the need for a CRM solution that empowers rather than constrains, which inspired us to create Twenty. We’re building the next-generation open-source CRM that offers you the flexibility to shape it according to your business objectives and meet your team’s unique needs. We’ve packed Twenty with powerful features to give you full control and help you win more deals.
|
||||
The need for a CRM solution that empowers rather than constrains was clear, which inspired us to create Twenty. It's a next-generation open-source CRM that offers you the flexibility to shape it according to your business objectives and meet your team’s unique needs. Twenty is full of powerful features to give you full control and help you win more deals.
|
||||
|
||||
## Getting started
|
||||
|
||||
@ -23,13 +23,13 @@ There are three ways for you to get started with Twenty:
|
||||
- **Local:** If you're a developer and would like to experiment or contribute to the app
|
||||
- **Self-hosting:** If you want greater control over your data and want to run the app on your own server
|
||||
|
||||
See our [Getting Started](./start/getting-started/) guide to learn more.
|
||||
See the [Getting Started](./start/getting-started/) guide to learn more.
|
||||
|
||||
## Contributing
|
||||
|
||||
Contributions are what makes the open source community such an amazing place.
|
||||
Contributions are what makes the open source community such a great place.
|
||||
|
||||
Code contributions through pull request are most welcome. See our [local setup guide](../contributor/local-setup) to get started.
|
||||
Code contributions through pull request are most welcome. See the [local setup guide](../contributor/local-setup) to get started.
|
||||
|
||||
You can also contribute by creating an issue to report a bug you've spotted, joining our discussions or writing documentation.
|
||||
You can also contribute by creating an issue to report a bug you've spotted, joining discussions or writing documentation.
|
||||
|
||||
|
@ -6,10 +6,8 @@ sidebar_custom_props:
|
||||
---
|
||||
|
||||
# Data collected
|
||||
We record pageview events using a unique identifier for each workspace/user.
|
||||
We also collect the workspace's domain.
|
||||
We do not use cookies for telemetry.
|
||||
We do not collect email addresses, names, phone numbers, dates of birth, addresses, usernames, or other PII.
|
||||
Twenty records pageview events using a unique identifier for each workspace/user, and collects the workspace's domain.
|
||||
Twenty does not use cookies for telemetry or collect email addresses, names, phone numbers, dates of birth, addresses, usernames, or other PII.
|
||||
|
||||
# Opting-out of telemetry
|
||||
To disable telemetry in your workspace, add the following line to your `server/.env` file:
|
||||
|
@ -11,17 +11,17 @@ import TabItem from '@theme/TabItem';
|
||||
There are three ways for you to get started with Twenty:
|
||||
### 1. Cloud
|
||||
|
||||
The easiest way to quickly try the app is to signup on [app.twenty.com](https://app.twenty.com).
|
||||
The easiest way to try the app is to sign up on [app.twenty.com](https://app.twenty.com).
|
||||
|
||||
The signup is free.
|
||||
The sign-up is free.
|
||||
|
||||
<ThemedImage sources={{light: "/img/light-sign-in.png", dark:"/img/dark-sign-in.png"}} style={{width:'100%', maxWidth:'800px'}}/>
|
||||
|
||||
### 2. Local
|
||||
If you're a developer and would like to experiment or contribute to the app, you can install Twenty on your local environment. Follow our [local setup](/contributor/local-setup) guide to get started.
|
||||
If you're a developer and would like to experiment or contribute to the app, you can install Twenty on your local environment. Follow the [local setup](/contributor/local-setup) guide to get started.
|
||||
|
||||
### 3. Self-hosting
|
||||
We provide [self-hosting options](/start/self-hosting) if you want greater control over your data and want to run the app on your own server. Right now, Docker containers are the only hosting option we support. However we are actively working on providing simple options to self-host Twenty.
|
||||
You can also find [self-hosting options](/start/self-hosting) if you want greater control over your data and want to run the app on your own server. Right now, Docker containers are the only hosting option available, with more simple options to self-host Twenty coming soon.
|
||||
|
||||
|
||||
___
|
||||
|
@ -4,12 +4,12 @@ sidebar_position: 2
|
||||
sidebar_custom_props:
|
||||
icon: TbServer
|
||||
---
|
||||
Right now, Docker containers are the only hosting option we support. However, we are actively working on providing simple options to self-host Twenty.
|
||||
Feel free to open issues on [Github](https://github.com/twentyhq/twenty/issues/new) if you want a specific cloud provider to be supported.
|
||||
Right now, Docker containers are the only hosting option available, with more simple options to self-host Twenty coming soon.
|
||||
Feel free to open issues on [GitHub](https://github.com/twentyhq/twenty/issues/new) if you want support for a specific cloud provider.
|
||||
|
||||
## Production docker containers
|
||||
|
||||
We provide a production-ready set of `Dockerfiles` to allow you to build your own image and deploy it to your favorite cloud provider (Amazon Web Services, Google Cloud Platform, etc.).
|
||||
The codebase includes production-ready set of `Dockerfiles` to allow you to build your own image and deploy it to your favorite cloud provider (Amazon Web Services, Google Cloud Platform, etc.).
|
||||
|
||||
You will find these in the [infra/prod/front/Dockerfile](https://github.com/twentyhq/twenty/blob/main/infra/prod/front/Dockerfile) and [infra/prod/server/Dockerfile](https://github.com/twentyhq/twenty/blob/main/infra/prod/server/Dockerfile) files.
|
||||
|
||||
@ -43,7 +43,7 @@ docker build \
|
||||
|
||||
## AWS Elastic Beanstalk (Coming soon)
|
||||
|
||||
We are working on providing a joint Docker image - containing both the Twenty frontend and server - that you can deploy using [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/).
|
||||
A joint Docker image - containing both the frontend and server - that you can deploy using [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) is in the works.
|
||||
|
||||
|
||||
<!--
|
||||
|
@ -7,7 +7,7 @@ sidebar_custom_props:
|
||||
|
||||
Objects are structures that allow you to store data (records, attributes, and values) specific to an organization. Twenty provides both standard and custom objects.
|
||||
|
||||
Standard objects are built-in objects with a set of attributes available for all users. All workspaces come with three standard objects by default: People, Companies, and Opportunities. Standard objects have standard fields that are also available for all Twenty users, like Account Owner and URL.
|
||||
Standard objects are in-built objects with a set of attributes available for all users. All workspaces come with three standard objects by default: People, Companies, and Opportunities. Standard objects have standard fields that are also available for all Twenty users, like Account Owner and URL.
|
||||
|
||||
Custom objects are objects that you can create to store information that is unique to your organization. They are not built-in; members of your workspace can create and customize custom objects to hold information that standard objects aren't suitable for. For example, if you're Airbnb, you may want to create a custom object for Listings or Reservations.
|
||||
|
||||
|
@ -16,8 +16,8 @@ Sync Twenty with 3000+ apps using [Zapier](https://zapier.com/), and automate yo
|
||||
1. Go to Zapier and log in.
|
||||
2. Click on `+ Create Zap` in the left sidebar.
|
||||
3. Choose the application you want to set as the trigger. A trigger refers to an event that starts the automation.
|
||||
4. Select Twenty as the action. An action is the event that is performed once the automation is triggered. [Learn more about triggers and actions in Zapier.](https://zapier.com/how-it-works)
|
||||
5. Once you choose the Twenty account that you want to use for your automation, you'll be prompted to authorize it by adding an API key. You can learn [how to generate your API key here.](generating-api-keys.mdx)
|
||||
4. Select Twenty as the action. An action is the event performed whenever an application triggers an automation. [Learn more about triggers and actions in Zapier.](https://zapier.com/how-it-works)
|
||||
5. Once you choose the Twenty account that you want to use for your automation, you'll have to authorize it by adding an API key. You can learn [how to generate your API key here.](generating-api-keys.mdx)
|
||||
6. Enter your API key and click on 'Yes, Continue to Twenty.'
|
||||
|
||||
<div style={{textAlign: 'center'}}>
|
||||
|
@ -16,11 +16,11 @@ To generate an API key:
|
||||
|
||||
:::caution Note
|
||||
|
||||
You API key contains sensitive information, and shouldn't be shared with services you don't fully trust. If leaked, it can be used maliciously. If you think your API key has been compromised, make sure you disable it and generate a new one.
|
||||
Since your API key contains sensitive information, you shouldn't share it with services you don't fully trust. If leaked, someone can use it maliciously. If you think your API key is no longer secure, make sure you disable it and generate a new one.
|
||||
|
||||
:::
|
||||
|
||||
|
||||
## Regenerating API key
|
||||
|
||||
To regenerate an API key, simply click on the key you want to regenerate. You'll then be able to see a button to regenerate the API key.
|
||||
To regenerate an API key, click on the key you want to regenerate. You'll then be able to see a button to regenerate the API key.
|
@ -6,15 +6,15 @@ sidebar_custom_props:
|
||||
---
|
||||
|
||||
### Company & People
|
||||
They are the two fundamental types of records that the CRM is built around:
|
||||
The CRM has two fundamental types of records:
|
||||
- A `Company` represents a business or organization.
|
||||
- `People` represent your company's current and prospective customers or clients.
|
||||
|
||||
### Pipelines
|
||||
A `Pipeline` is a way to track a business process. Pipelines are categorized within a *module* and have *stages*:
|
||||
A `Pipeline` is a way to track a business process. Pipelines are present within a *module* and have *stages*:
|
||||
- A **module** contains the logic for a certain business process (for example: sales, recruiting).
|
||||
- **Stages** map the steps in your process (for example: new, ongoing, won, lost).
|
||||
|
||||
### Workspace
|
||||
A `Workspace` usually represents a company using Twenty.
|
||||
It is attached to a single domain name, which is usually the domain name your company uses for employee email addresses.
|
||||
A `Workspace` typically represents a company using Twenty.
|
||||
It has a single domain name, which is typically the domain name your company uses for employee email addresses.
|
||||
|
@ -10,15 +10,15 @@ sidebar_custom_props:
|
||||
|
||||
# Welcome to Twenty's User Guide
|
||||
|
||||
This user guide is intended to help you learn how you can use Twenty to build the CRM you want.
|
||||
The purpose of this user guide is to help you learn how you can use Twenty to build the CRM you want.
|
||||
|
||||
In this quick-start guide, we'll walk you through the basics.
|
||||
This quick-start guide walks you through the basics.
|
||||
|
||||
## Quick Search
|
||||
|
||||
You'll see a search bar at the top of your sidebar. You can also bring up the command bar with the `cmd`/`ctrl` + `k` shortcut to quickly navigate through your workspace, and find people, companies, notes, and more.
|
||||
You'll see a search bar at the top of your sidebar. You can also bring up the command bar with the `cmd`/`ctrl` + `k` shortcut to navigate through your workspace, and find people, companies, notes, and more.
|
||||
|
||||
The command bar also supports numerous shortcuts for navigation.
|
||||
The command bar also supports other shortcuts for navigation.
|
||||
|
||||
## Create Pre-filtered Views
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user