-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REFACTOR] Split in two distinct forms Settings Object Model page #10653
Conversation
Just discovered that we can corrup a workspace by sending an empty |
@greptileai trigger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR Summary
Here's my review of the changes in this pull request:
This PR refactors the Object Model settings page by splitting it into two distinct forms (SettingsDataModelObjectAboutForm and SettingsDataModelObjectSettingsFormCard) with improved validation and error handling.
Key changes:
- Added
settingsDataModelObjectAboutFormSchema
with required fields (description, icon, labels) and optional fields (names, sync settings) - Created new
SettingsUpdateDataModelObjectAboutForm
wrapper component to handle object metadata updates - Introduced
ReadonlyKeysArray
andzodNonEmptyString
types for improved type safety - Implemented custom validation rules for label/name differences and camelCase formatting
- Removed debug console.log in
SettingsUpdateDataModelObjectAboutForm.tsx
that should be cleaned up
The refactoring improves code organization and maintainability, but there are a few items that need attention:
- Remove console.log statement in
SettingsUpdateDataModelObjectAboutForm
- Consider adding error boundary around form components for better error handling
- Verify form submission timing with the new
onNewDirtyField
approach to prevent race conditions
15 file(s) reviewed, 13 comment(s)
Edit PR Review Bot Settings | Greptile
...les/settings/data-model/object-details/components/SettingsUpdateDataModelObjectAboutForm.tsx
Outdated
Show resolved
Hide resolved
...les/settings/data-model/object-details/components/SettingsUpdateDataModelObjectAboutForm.tsx
Show resolved
Hide resolved
...les/settings/data-model/object-details/components/SettingsUpdateDataModelObjectAboutForm.tsx
Show resolved
Hide resolved
...les/settings/data-model/object-details/components/SettingsUpdateDataModelObjectAboutForm.tsx
Outdated
Show resolved
Hide resolved
...les/settings/data-model/object-details/components/SettingsUpdateDataModelObjectAboutForm.tsx
Show resolved
Hide resolved
...src/modules/settings/data-model/validation-schemas/settingsDataModelObjectAboutFormSchema.ts
Outdated
Show resolved
Hide resolved
...src/modules/settings/data-model/validation-schemas/settingsDataModelObjectAboutFormSchema.ts
Outdated
Show resolved
Hide resolved
...src/modules/settings/data-model/validation-schemas/settingsDataModelObjectAboutFormSchema.ts
Outdated
Show resolved
Hide resolved
...src/modules/settings/data-model/validation-schemas/settingsDataModelObjectAboutFormSchema.ts
Outdated
Show resolved
Hide resolved
@greptileai trigger |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR Summary
(updates since last review)
This update focuses on refining the validation schema for the Object Model settings page with improved error handling and field validation.
Key changes:
- Updated
settingsDataModelObjectAboutFormSchema.ts
to enforce case-insensitive comparison usingtrim().toLowerCase()
for label/name validation - Changed description field to use
nullish()
instead ofoptional()
in form schema - Added camelCase validation for
nameSingular
andnamePlural
fields usingcamelCaseStringSchema
- Implemented
zodNonEmptyString
validation to prevent empty string values
The changes improve data validation while maintaining clean code structure. Note that server-side empty string validation is still pending implementation.
1 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile
...src/modules/settings/data-model/validation-schemas/settingsDataModelObjectAboutFormSchema.ts
Show resolved
Hide resolved
packages/twenty-front/src/modules/settings/constants/SettingsObjectModel.ts
Show resolved
Hide resolved
packages/twenty-front/src/modules/settings/constants/SettingsObjectModel.ts
Show resolved
Hide resolved
...src/modules/settings/data-model/validation-schemas/settingsDataModelObjectAboutFormSchema.ts
Show resolved
Hide resolved
packages/twenty-front/src/pages/settings/data-model/SettingsNewObject.tsx
Show resolved
Hide resolved
...les/settings/data-model/objects/forms/components/SettingsDataModelObjectSettingsFormCard.tsx
Show resolved
Hide resolved
const result = settingsDataModelObjectAboutFormSchema.safeParse(input); | ||
expect(result.success).toBe(expectedSuccess); | ||
if (!expectedSuccess) { | ||
expect(result.error).toMatchSnapshot(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am new to snapshotting in JEST. Correct me if I am wrong, but this is JEST that created the folder snapshot and its containg file.
Question: UI test tend to be flaky. even though I see in the doc the jest update function, it will break the CI. Are we ok and aware with implementing this as if a unit test ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am new to snapshotting in JEST. Correct me if I am wrong, but this is JEST that created the folder snapshot and its containg file.
Exactly
Question: UI test tend to be flaky. even though I see in the doc the jest update function, it will break the CI. Are we ok and aware with implementing this ?
I think you're mistaking e2e tests and unit/integrations tests which by definition should be way less flaky ( querying a DOM always is etc etc), but regarding this PR tests suite we should never have flakiness as these are very low level javascript unit tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. But if we add a field to the form, do we want to break the test ? Answer could be yes, if we consider its a cruacial part. that's my point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my opinion yes, but before the test to fail, TypeScript would also raises regarding test definition itself saying: dude your mocks does not relate my inner types
Note that updating snapshot is pretty easy, but rely on the fact that users will review them
I always tend to snapshot errors because no need to be very strict
Regarding huge data set I'm not a fan, or at least binded with atomic assertion such as done within useDeleteOne.test.ts
test suite with Apollo cache
@guillim Thank you for the advanced mode issue, nice catch ! 🚀 Fixed the form to always have a default value for the |
...rc/modules/settings/data-model/objects/forms/components/SettingsDataModelObjectAboutForm.tsx
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great job @prastoin !!!
# Introduction This PR contains several SNAPSHOT files explaining big + While refactoring the Object Model settings page in #10653, encountered a critical issue when submitting either one or both names with `""` empty string hard corrupting a workspace. This motivate this PR reviewing server side validation I feel like we could share zod schema between front and back ## Refactored server validation What to expect from Names: - Plural and singular have to be different ( case insensitive and trimmed check ) - Contains only a-z A-Z and 0-9 - Follows camelCase - Is not empty => Is not too short ( 1 ) - Is not too long ( 63 ) - Is case insensitive( fooBar and fOoBar now rejected ) What to expect from Labels: - Plural and singular have to be different ( case insensitive and trimmed check ) - Is not empty => Is not too short ( 1 ) - Is not too long ( 63 ) - Is case insensitive ( fooBar and fOoBar now rejected ) close #10694 ## Creation integrations tests Created new integrations tests, following [EachTesting](https://jestjs.io/docs/api#testeachtablename-fn-timeout) pattern and uses snapshot to assert errors message. These tests cover several failing use cases and started to implement ones for the happy path but object metadata item deletion is currently broken unless I'm mistaken @Weiko is on it ## Notes - [ ] As we've added new validation rules towards names and labels we should scan db in order to standardize existing values using either a migration command or manual check - [ ] Will review in an other PR the update path, adding integrations tests and so on
Introduction
This PR contains around ~+300 tests + snapshot additions
Please check both object model creation and edition
Closes twentyhq/core-team-issues#355
Refactored into two agnostic forms the Object Model settings page for instance
/settings/objects/notes#settings
.SettingsDataModelObjectAboutForm
Added a new abstraction
SettingsUpdateDataModelObjectAboutForm
to wrapSettingsDataModelObjectAboutForm
in anupdate
contextSchema:
SettingsDataModelObjectSettingsFormCard
Update on change

Schema:
Error management and validation schema
Improved the frontend validation form in order to attest that:
Hide the error messages as we need to decide what kind of styling we want for our errors with forms

( Example with error labels )