2023-12-10 17:10:54 +00:00
|
|
|
{
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"workspaceLayout": {
|
|
|
|
|
"appsDir": "packages",
|
|
|
|
|
"libsDir": "packages"
|
|
|
|
|
},
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"namedInputs": {
|
2025-08-12 11:12:03 +00:00
|
|
|
"default": ["{projectRoot}/**/*"],
|
2024-05-03 12:59:09 +00:00
|
|
|
"excludeStories": [
|
|
|
|
|
"default",
|
|
|
|
|
"!{projectRoot}/.storybook/*",
|
|
|
|
|
"!{projectRoot}/**/tsconfig.storybook.json",
|
|
|
|
|
"!{projectRoot}/**/*.stories.(ts|tsx)",
|
|
|
|
|
"!{projectRoot}/**/__stories__/*"
|
|
|
|
|
],
|
|
|
|
|
"excludeTests": [
|
|
|
|
|
"default",
|
|
|
|
|
"!{projectRoot}/**/jest.config.(js|ts)",
|
|
|
|
|
"!{projectRoot}/**/tsconfig.spec.json",
|
|
|
|
|
"!{projectRoot}/**/*.test.(ts|tsx)",
|
|
|
|
|
"!{projectRoot}/**/*.spec.(ts|tsx)",
|
2025-01-09 17:30:41 +00:00
|
|
|
"!{projectRoot}/**/*.integration-spec.ts",
|
2024-05-03 12:59:09 +00:00
|
|
|
"!{projectRoot}/**/__tests__/*"
|
|
|
|
|
],
|
|
|
|
|
"production": [
|
|
|
|
|
"default",
|
|
|
|
|
"excludeStories",
|
|
|
|
|
"excludeTests",
|
|
|
|
|
"!{projectRoot}/**/__mocks__/*",
|
|
|
|
|
"!{projectRoot}/**/testing/*"
|
|
|
|
|
]
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
},
|
2023-12-10 17:10:54 +00:00
|
|
|
"targetDefaults": {
|
|
|
|
|
"build": {
|
|
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"inputs": ["^production", "production"],
|
|
|
|
|
"dependsOn": ["^build"]
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
},
|
|
|
|
|
"start": {
|
|
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"]
|
2023-12-10 17:10:54 +00:00
|
|
|
},
|
|
|
|
|
"lint": {
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"executor": "@nx/eslint:lint",
|
|
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"outputs": ["{options.outputFile}"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"options": {
|
2025-08-12 11:12:03 +00:00
|
|
|
"eslintConfig": "{projectRoot}/eslint.config.mjs",
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"cache": true,
|
2025-08-10 21:25:58 +00:00
|
|
|
"cacheLocation": "{workspaceRoot}/.cache/eslint"
|
2025-08-08 14:21:57 +00:00
|
|
|
},
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"configurations": {
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"ci": {
|
|
|
|
|
"cacheStrategy": "content"
|
|
|
|
|
},
|
|
|
|
|
"fix": {
|
|
|
|
|
"fix": true
|
|
|
|
|
}
|
2024-12-17 08:24:21 +00:00
|
|
|
},
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"]
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
},
|
|
|
|
|
"fmt": {
|
|
|
|
|
"executor": "nx:run-commands",
|
|
|
|
|
"cache": true,
|
|
|
|
|
"options": {
|
|
|
|
|
"cwd": "{projectRoot}",
|
|
|
|
|
"command": "prettier {args.files} --check --cache {args.cache} --cache-location {args.cacheLocation} --write {args.write} --cache-strategy {args.cacheStrategy}",
|
|
|
|
|
"cache": true,
|
|
|
|
|
"cacheLocation": "../../.cache/prettier/{projectRoot}",
|
|
|
|
|
"cacheStrategy": "metadata",
|
|
|
|
|
"write": false
|
|
|
|
|
},
|
|
|
|
|
"configurations": {
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"ci": {
|
|
|
|
|
"cacheStrategy": "content"
|
|
|
|
|
},
|
|
|
|
|
"fix": {
|
|
|
|
|
"write": true
|
|
|
|
|
}
|
2024-12-17 08:24:21 +00:00
|
|
|
},
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"]
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
},
|
|
|
|
|
"typecheck": {
|
|
|
|
|
"executor": "nx:run-commands",
|
|
|
|
|
"cache": true,
|
|
|
|
|
"options": {
|
|
|
|
|
"cwd": "{projectRoot}",
|
|
|
|
|
"command": "tsc -b tsconfig.json --incremental"
|
|
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"configurations": {
|
|
|
|
|
"watch": {
|
|
|
|
|
"watch": true
|
|
|
|
|
}
|
|
|
|
|
},
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"]
|
2023-12-10 17:10:54 +00:00
|
|
|
},
|
|
|
|
|
"test": {
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"executor": "@nx/jest:jest",
|
2024-01-29 09:17:12 +00:00
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"],
|
2024-05-03 12:59:09 +00:00
|
|
|
"inputs": [
|
|
|
|
|
"^default",
|
|
|
|
|
"excludeStories",
|
|
|
|
|
"{workspaceRoot}/jest.preset.js"
|
|
|
|
|
],
|
2025-08-12 11:12:03 +00:00
|
|
|
"outputs": ["{projectRoot}/coverage"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"options": {
|
2025-08-19 16:10:35 +00:00
|
|
|
"jestConfig": "{projectRoot}/jest.config.mjs",
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"coverage": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"coverageReporters": ["text-summary"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"cacheDirectory": "../../.cache/jest/{projectRoot}"
|
|
|
|
|
},
|
|
|
|
|
"configurations": {
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"ci": {
|
|
|
|
|
"ci": true,
|
|
|
|
|
"maxWorkers": 3
|
|
|
|
|
},
|
|
|
|
|
"coverage": {
|
2025-08-12 11:12:03 +00:00
|
|
|
"coverageReporters": ["lcov", "text"]
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
},
|
|
|
|
|
"watch": {
|
|
|
|
|
"watch": true
|
|
|
|
|
}
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
}
|
2023-12-10 17:10:54 +00:00
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"test:e2e": {
|
|
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"]
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
},
|
2024-04-04 13:38:01 +00:00
|
|
|
"storybook:build": {
|
2024-05-07 19:05:45 +00:00
|
|
|
"executor": "nx:run-commands",
|
2024-04-04 13:38:01 +00:00
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"inputs": ["^default", "excludeTests"],
|
|
|
|
|
"outputs": ["{projectRoot}/{options.output-dir}"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"options": {
|
2024-05-07 19:05:45 +00:00
|
|
|
"cwd": "{projectRoot}",
|
2025-08-10 21:25:58 +00:00
|
|
|
"command": "VITE_DISABLE_TYPESCRIPT_CHECKER=true VITE_DISABLE_ESLINT_CHECKER=true storybook build --test",
|
2024-05-07 19:05:45 +00:00
|
|
|
"output-dir": "storybook-static",
|
|
|
|
|
"config-dir": ".storybook"
|
2024-12-17 08:24:21 +00:00
|
|
|
},
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"]
|
2024-04-04 13:38:01 +00:00
|
|
|
},
|
2024-06-30 18:02:13 +00:00
|
|
|
"storybook:serve:dev": {
|
2024-05-07 19:05:45 +00:00
|
|
|
"executor": "nx:run-commands",
|
2024-04-04 13:38:01 +00:00
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"options": {
|
2024-05-07 19:05:45 +00:00
|
|
|
"cwd": "{projectRoot}",
|
|
|
|
|
"command": "storybook dev",
|
|
|
|
|
"config-dir": ".storybook"
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
}
|
|
|
|
|
},
|
2024-06-30 18:02:13 +00:00
|
|
|
"storybook:serve:static": {
|
2024-05-07 19:05:45 +00:00
|
|
|
"executor": "nx:run-commands",
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["storybook:build"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"options": {
|
2024-05-07 19:05:45 +00:00
|
|
|
"cwd": "{projectRoot}",
|
|
|
|
|
"command": "npx http-server {args.staticDir} -a={args.host} --port={args.port} --silent={args.silent}",
|
|
|
|
|
"staticDir": "storybook-static",
|
|
|
|
|
"host": "localhost",
|
|
|
|
|
"port": 6006,
|
|
|
|
|
"silent": true
|
2024-05-03 12:59:09 +00:00
|
|
|
}
|
|
|
|
|
},
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"storybook:test": {
|
|
|
|
|
"executor": "nx:run-commands",
|
2024-05-03 12:59:09 +00:00
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"inputs": ["^default", "excludeTests"],
|
|
|
|
|
"outputs": ["{projectRoot}/coverage/storybook"],
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"options": {
|
2024-05-03 12:59:09 +00:00
|
|
|
"cwd": "{projectRoot}",
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
"commands": [
|
2025-01-10 17:40:03 +00:00
|
|
|
"test-storybook --url http://localhost:{args.port} --maxWorkers=3 --coverage --coverageDirectory={args.coverageDir} --shard={args.shard}",
|
|
|
|
|
"nx storybook:coverage {projectName} --coverageDir={args.coverageDir} --checkCoverage={args.checkCoverage}"
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
],
|
2025-01-10 17:40:03 +00:00
|
|
|
"shard": "1/1",
|
2024-05-02 14:15:36 +00:00
|
|
|
"parallel": false,
|
2024-05-03 12:59:09 +00:00
|
|
|
"coverageDir": "coverage/storybook",
|
2025-01-10 17:40:03 +00:00
|
|
|
"port": 6006,
|
|
|
|
|
"checkCoverage": true
|
2024-05-03 12:59:09 +00:00
|
|
|
}
|
|
|
|
|
},
|
2024-06-30 18:02:13 +00:00
|
|
|
"storybook:test:no-coverage": {
|
Generic Profiling story to wrap any component (#5341)
This PR introduces a Profiling feature for our story book tests.
It also implements a new CI job : front-sb-test-performance, that only
runs stories suffixed with `.perf.stories.tsx`
## How it works
It allows to wrap any component into an array of React Profiler
components that will run tests many times to have the most replicable
average render time possible.
It is simply used by calling the new `getProfilingStory` util.
Internally it creates a defined number of tests, separated by an
arbitrary waiting time to allow the CPU to give more stable results.
It will do 3 warm-up and 3 finishing runs of tests because the first and
last renders are always a bit erratic, so we want to measure only the
runs in-between.
On the UI side it gives a table of results :
<img width="515" alt="image"
src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993">
On the programmatic side, it stores the result in a div that can then be
parsed by the play fonction of storybook, to expect a defined threshold.
```tsx
play: async ({ canvasElement }) => {
await findByTestId(
canvasElement,
'profiling-session-finished',
{},
{ timeout: 60000 },
);
const profilingReport = getProfilingReportFromDocument(canvasElement);
if (!isDefined(profilingReport)) {
return;
}
const p95result = profilingReport?.total.p95;
expect(
p95result,
`Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`,
).toBeLessThan(p95ThresholdInMs);
},
```
2024-05-15 11:50:02 +00:00
|
|
|
"executor": "nx:run-commands",
|
2025-08-12 11:12:03 +00:00
|
|
|
"inputs": ["^default", "excludeTests"],
|
Generic Profiling story to wrap any component (#5341)
This PR introduces a Profiling feature for our story book tests.
It also implements a new CI job : front-sb-test-performance, that only
runs stories suffixed with `.perf.stories.tsx`
## How it works
It allows to wrap any component into an array of React Profiler
components that will run tests many times to have the most replicable
average render time possible.
It is simply used by calling the new `getProfilingStory` util.
Internally it creates a defined number of tests, separated by an
arbitrary waiting time to allow the CPU to give more stable results.
It will do 3 warm-up and 3 finishing runs of tests because the first and
last renders are always a bit erratic, so we want to measure only the
runs in-between.
On the UI side it gives a table of results :
<img width="515" alt="image"
src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993">
On the programmatic side, it stores the result in a div that can then be
parsed by the play fonction of storybook, to expect a defined threshold.
```tsx
play: async ({ canvasElement }) => {
await findByTestId(
canvasElement,
'profiling-session-finished',
{},
{ timeout: 60000 },
);
const profilingReport = getProfilingReportFromDocument(canvasElement);
if (!isDefined(profilingReport)) {
return;
}
const p95result = profilingReport?.total.p95;
expect(
p95result,
`Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`,
).toBeLessThan(p95ThresholdInMs);
},
```
2024-05-15 11:50:02 +00:00
|
|
|
"options": {
|
|
|
|
|
"cwd": "{projectRoot}",
|
|
|
|
|
"commands": [
|
2024-07-13 20:30:11 +00:00
|
|
|
"test-storybook --url http://localhost:{args.port} --maxWorkers=2"
|
Generic Profiling story to wrap any component (#5341)
This PR introduces a Profiling feature for our story book tests.
It also implements a new CI job : front-sb-test-performance, that only
runs stories suffixed with `.perf.stories.tsx`
## How it works
It allows to wrap any component into an array of React Profiler
components that will run tests many times to have the most replicable
average render time possible.
It is simply used by calling the new `getProfilingStory` util.
Internally it creates a defined number of tests, separated by an
arbitrary waiting time to allow the CPU to give more stable results.
It will do 3 warm-up and 3 finishing runs of tests because the first and
last renders are always a bit erratic, so we want to measure only the
runs in-between.
On the UI side it gives a table of results :
<img width="515" alt="image"
src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993">
On the programmatic side, it stores the result in a div that can then be
parsed by the play fonction of storybook, to expect a defined threshold.
```tsx
play: async ({ canvasElement }) => {
await findByTestId(
canvasElement,
'profiling-session-finished',
{},
{ timeout: 60000 },
);
const profilingReport = getProfilingReportFromDocument(canvasElement);
if (!isDefined(profilingReport)) {
return;
}
const p95result = profilingReport?.total.p95;
expect(
p95result,
`Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`,
).toBeLessThan(p95ThresholdInMs);
},
```
2024-05-15 11:50:02 +00:00
|
|
|
],
|
|
|
|
|
"port": 6006
|
|
|
|
|
}
|
|
|
|
|
},
|
2024-06-30 18:02:13 +00:00
|
|
|
"storybook:coverage": {
|
|
|
|
|
"executor": "nx:run-commands",
|
|
|
|
|
"cache": true,
|
|
|
|
|
"inputs": [
|
|
|
|
|
"^default",
|
|
|
|
|
"excludeTests",
|
|
|
|
|
"{projectRoot}/coverage/storybook/coverage-storybook.json"
|
|
|
|
|
],
|
|
|
|
|
"outputs": [
|
|
|
|
|
"{projectRoot}/coverage/storybook",
|
|
|
|
|
"!{projectRoot}/coverage/storybook/coverage-storybook.json"
|
|
|
|
|
],
|
|
|
|
|
"options": {
|
2025-01-10 17:40:03 +00:00
|
|
|
"command": "npx nyc report --reporter={args.reporter} --reporter=text-summary -t {args.coverageDir} --report-dir {args.coverageDir} --check-coverage={args.checkCoverage} --cwd={projectRoot}",
|
2024-06-30 18:02:13 +00:00
|
|
|
"coverageDir": "coverage/storybook",
|
2025-01-10 17:40:03 +00:00
|
|
|
"reporter": "lcov",
|
|
|
|
|
"checkCoverage": true
|
2024-06-30 18:02:13 +00:00
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"configurations": {
|
|
|
|
|
"text": {
|
|
|
|
|
"reporter": "text"
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-06-30 18:02:13 +00:00
|
|
|
},
|
|
|
|
|
"storybook:serve-and-test:static": {
|
2024-05-03 12:59:09 +00:00
|
|
|
"executor": "nx:run-commands",
|
|
|
|
|
"options": {
|
|
|
|
|
"commands": [
|
2025-01-10 17:40:03 +00:00
|
|
|
"npx concurrently --kill-others --success=first -n SB,TEST 'nx storybook:serve:static {projectName} --port={args.port}' 'npx wait-on tcp:{args.port} && nx storybook:test {projectName} --shard={args.shard} --checkCoverage={args.checkCoverage} --port={args.port} --configuration={args.scope}'"
|
Generic Profiling story to wrap any component (#5341)
This PR introduces a Profiling feature for our story book tests.
It also implements a new CI job : front-sb-test-performance, that only
runs stories suffixed with `.perf.stories.tsx`
## How it works
It allows to wrap any component into an array of React Profiler
components that will run tests many times to have the most replicable
average render time possible.
It is simply used by calling the new `getProfilingStory` util.
Internally it creates a defined number of tests, separated by an
arbitrary waiting time to allow the CPU to give more stable results.
It will do 3 warm-up and 3 finishing runs of tests because the first and
last renders are always a bit erratic, so we want to measure only the
runs in-between.
On the UI side it gives a table of results :
<img width="515" alt="image"
src="https://github.com/twentyhq/twenty/assets/26528466/273d2d91-26da-437a-890e-778cb6c1f993">
On the programmatic side, it stores the result in a div that can then be
parsed by the play fonction of storybook, to expect a defined threshold.
```tsx
play: async ({ canvasElement }) => {
await findByTestId(
canvasElement,
'profiling-session-finished',
{},
{ timeout: 60000 },
);
const profilingReport = getProfilingReportFromDocument(canvasElement);
if (!isDefined(profilingReport)) {
return;
}
const p95result = profilingReport?.total.p95;
expect(
p95result,
`Component render time is more than p95 threshold (${p95ThresholdInMs}ms)`,
).toBeLessThan(p95ThresholdInMs);
},
```
2024-05-15 11:50:02 +00:00
|
|
|
],
|
2025-01-10 17:40:03 +00:00
|
|
|
"shard": "1/1",
|
|
|
|
|
"checkCoverage": true,
|
2024-05-02 14:15:36 +00:00
|
|
|
"port": 6006
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"chromatic": {
|
|
|
|
|
"executor": "nx:run-commands",
|
|
|
|
|
"options": {
|
|
|
|
|
"cwd": "{projectRoot}",
|
2024-05-22 09:18:16 +00:00
|
|
|
"commands": [
|
|
|
|
|
{
|
2024-06-30 18:02:13 +00:00
|
|
|
"command": "nx storybook:build {projectName}",
|
2024-05-22 09:18:16 +00:00
|
|
|
"forwardAllArgs": false
|
|
|
|
|
},
|
|
|
|
|
"cross-var chromatic --project-token=$CHROMATIC_PROJECT_TOKEN --storybook-build-dir=storybook-static {args.ci}"
|
|
|
|
|
],
|
|
|
|
|
"parallel": false
|
chore: use Nx affected tasks in CI (#5110)
Closes #5097
- Uses "nx affected" to detect what projects need to be checked in the
current PR (for now, `ci-front` and `ci-server` workflows only).
- Caches results of certain tasks (`lint`, `typecheck`, `test`,
`storybook:build`) when a PR pipeline runs. The next runs of the same
PR's pipeline will then be able to reuse the PR's task cache to execute
tasks faster.
- Caches Yarn's cache folder to install dependencies faster in CI jobs.
- Rewrites the node modules cache/install steps as a custom, reusable
Github action.
- Distributes `ci-front` jobs with a "matrix" strategy.
- Sets common tasks config at the root `nx.json`. For instance, to
activate the `typecheck` task in a project, add `typecheck: {}` to its
`project.json` and it'll use the default config set in `nx.json` for the
`typecheck` task. Options can be overridden in each individual
`project.json` if needed.
- Adds "scope" tags to some projects: `scope:frontend`, `scope:backend`,
`scope:shared`. An eslint rule ensures that `scope:frontend` only
depends on `scope:frontent` or `scope:shared` projects, same for
`scope:backend`. These tags are used by `nx affected` to filter projects
by scope and generates different task cache keys according to the
requested scope.
- Enables checks for twenty-emails in the `ci-server` workflow.
2024-04-30 14:28:25 +00:00
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"configurations": {
|
|
|
|
|
"ci": {
|
|
|
|
|
"ci": "--exit-zero-on-changes"
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-04-04 13:38:01 +00:00
|
|
|
},
|
2024-01-03 22:07:25 +00:00
|
|
|
"@nx/jest:jest": {
|
|
|
|
|
"cache": true,
|
2024-05-03 12:59:09 +00:00
|
|
|
"inputs": [
|
|
|
|
|
"^default",
|
|
|
|
|
"excludeStories",
|
|
|
|
|
"{workspaceRoot}/jest.preset.js"
|
|
|
|
|
],
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"options": {
|
|
|
|
|
"passWithNoTests": true
|
|
|
|
|
},
|
|
|
|
|
"configurations": {
|
|
|
|
|
"ci": {
|
|
|
|
|
"ci": true,
|
|
|
|
|
"codeCoverage": true
|
|
|
|
|
}
|
|
|
|
|
}
|
2024-01-29 09:17:12 +00:00
|
|
|
},
|
2024-04-01 11:16:50 +00:00
|
|
|
"@nx/eslint:lint": {
|
2024-01-29 09:17:12 +00:00
|
|
|
"cache": true,
|
2024-04-01 11:16:50 +00:00
|
|
|
"inputs": [
|
|
|
|
|
"default",
|
2025-08-12 11:12:03 +00:00
|
|
|
"{workspaceRoot}/eslint.config.mjs",
|
2024-04-01 11:16:50 +00:00
|
|
|
"{workspaceRoot}/tools/eslint-rules/**/*"
|
|
|
|
|
]
|
2024-04-04 10:30:49 +00:00
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"@nx/vite:test": {
|
|
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"inputs": ["default", "^default"]
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
},
|
2024-04-04 10:30:49 +00:00
|
|
|
"@nx/vite:build": {
|
|
|
|
|
"cache": true,
|
2025-08-12 11:12:03 +00:00
|
|
|
"dependsOn": ["^build"],
|
|
|
|
|
"inputs": ["default", "^default"]
|
2023-12-10 17:10:54 +00:00
|
|
|
}
|
|
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"installation": {
|
|
|
|
|
"version": "21.3.11"
|
|
|
|
|
},
|
2024-01-29 09:17:12 +00:00
|
|
|
"generators": {
|
|
|
|
|
"@nx/react": {
|
|
|
|
|
"application": {
|
2024-04-04 13:38:01 +00:00
|
|
|
"style": "@emotion/styled",
|
|
|
|
|
"linter": "eslint",
|
|
|
|
|
"bundler": "vite",
|
|
|
|
|
"compiler": "swc",
|
|
|
|
|
"unitTestRunner": "jest",
|
|
|
|
|
"projectNameAndRootFormat": "derived"
|
2024-01-29 09:17:12 +00:00
|
|
|
},
|
|
|
|
|
"library": {
|
2024-04-04 13:38:01 +00:00
|
|
|
"style": "@emotion/styled",
|
|
|
|
|
"linter": "eslint",
|
|
|
|
|
"bundler": "vite",
|
|
|
|
|
"compiler": "swc",
|
|
|
|
|
"unitTestRunner": "jest",
|
|
|
|
|
"projectNameAndRootFormat": "derived"
|
|
|
|
|
},
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"component": {
|
|
|
|
|
"style": "@emotion/styled"
|
|
|
|
|
}
|
2024-01-29 09:17:12 +00:00
|
|
|
}
|
2024-03-13 13:21:18 +00:00
|
|
|
},
|
|
|
|
|
"tasksRunnerOptions": {
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
"default": {
|
|
|
|
|
"options": {
|
2025-08-12 11:12:03 +00:00
|
|
|
"cacheableOperations": ["storybook:build"]
|
Refactor usePersistField (#13775)
This PR introduces refactors and tradeoffs in the API around the events
of field input.
# Refactored usePersistField
The hook `usePersistField` has been refactored to be used anywhere in
the app, not just inside a FieldContext.
This was meant to solve a bug at the beginning but now it is just used
once in `RecordDetailRelationSection` outside of the context, still this
is better to have this hook like that for future use cases.
We also introduce `usePersistFieldFromFieldInputContext`, for an easier
API inside a FieldContext.
# Introduced a new `FieldInputEventContext`
To remove the drill-down of events, we introduce
`FieldInputEventContext`, this allows to set only once the handlers /
events. In practice it allows to have an easier time maintaining the
events for the many different field inputs, because it matches the
pattern we already use of taking everything from a context
(`FieldContext`).
# Removed drill-down from FieldInput
The heavy drill-down in FieldInput has been completely removed, since
everything can be derived from `FieldContext` and
`FieldInputEventContext`.
Also there was some readonly and other specific props, but they were all
drilled down from FieldContext, so it was easier to just use
FieldContext where needed.
# Refactored events of `MultiItemFieldInputProps`
The component `MultiItemFieldInputProps` has a contrived API, here we
just remove the complex part that was persisting from inside.
We now only give a classic API with `onChange` and `onEscape` the rest
is left to higher levels, where it should be, because this generic
component shouldn't be aware of persisting things.
# Extracted the parsing logic of persisted values
For each input field component, we now have a clear util that was before
bound to the persist call,
# Tradeoff with persist times
The tradeoff before was that persistField was called anywhere, before
exiting the component sometimes, now it is only called by the higher
levels like table or show page, which handles this abstraction.
This could be challenged, however I think that having a lot of different
events, and not just `handleSubmit` and `handleCancel`, convey enough
meaning for the higher levels to decide what to do in each case.
A `skipPersist` argument was added in events in the rare edge cases
where we want to voluntarily skip persisting even with a submit or
escape, but that could be challenged because we could also say that we
should use cancel for that and stick to that convention.
# Handling of the bug in `ActivityRichTextEditor`
Initially this refactor was prioritized for solving this bug, which was
very annoying for the users.
But while fixing it with the new persistField hook I just understood
that the problem is not just for record title cells but for anything
that is open when we click on a rich text editor.
The issue is described here :
https://github.com/twentyhq/core-team-issues/issues/1317
So right now I just let it as is.
# Stories
The stories were checking that a request was sent in some cases where
persist was called before a component exiting, now that persist is only
called by higher-levels I just removed those tests from the stories,
because that should be the responsibility of higher levels.
Also a helper `getFieldInputEventContextProviderWithJestMocks` was
created that exposes a context and jest mock functions for testing this
new API in stories.
# Miscellaneous
Deactivated tui with nx by default, because it can be annoying.
2025-08-12 08:42:13 +00:00
|
|
|
}
|
|
|
|
|
}
|
2024-04-01 11:16:50 +00:00
|
|
|
},
|
|
|
|
|
"useInferencePlugins": false,
|
2025-08-13 15:50:10 +00:00
|
|
|
"defaultBase": "main",
|
|
|
|
|
"tui": {
|
|
|
|
|
"enabled": false
|
|
|
|
|
}
|
2025-08-19 16:10:35 +00:00
|
|
|
}
|