-
Notifications
You must be signed in to change notification settings - Fork 0
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
Enforce custom type keys are lowercase #47
Conversation
Co-authored-by: Lizzy Ballantine <lizzy.kayballantine@gmail.com>
We are adding another one soon Co-authored-by: Lizzy Ballantine <lizzy.kayballantine@gmail.com>
dbd055a
to
100457d
Compare
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.
Lovely stuff 👌
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.
Nice one! My only feedback is around ensure we highlight (on the commit message and not only on the PR description) that this behaviour is just enforced for custom type definition and not across all blocks, menus and so on that do have a schema definition too. Hope this makes sense.
@@ -38,6 +38,7 @@ def validate | |||
ensure_has_required_keys && |
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.
Could we add to the commit message that this behaviour is for the schema definition of the custom types and not "all possible schemas"?
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.
We store custom types in the database with a requirement to have keys unique within a theme. This validation is case sensitive; currently, it's possible to create multiple version of the same type with names like `type` and `Type`. Changing this validation to case insensitive in the persistence layer could lead into themes failing to load custom types in the future. (Now it's guaranteed to be unique as the first time load from the theme creates the first custom types.) To ensure integrity across all layers, we want to enforce lowercase keys at the point of custom type validation. Co-authored-by: Lizzy Ballantine <lizzy.kayballantine@gmail.com>
To guarantee interoperatibility with current attribute and block schemas, ensure that custom type lookup for validation is case insensitive.
Due to incompatible key validation changes Co-authored-by: Lizzy Ballantine <lizzy.kayballantine@gmail.com>
100457d
to
54982c4
Compare
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.
Amazing!
A creator was unable to delete an image which was part of a custom type with a name like
meetTheCard
. The cause was a type mismatch caused by downcasing. We opted to enforce consistent casing.To ensure integrity across all layers, we want to enforce lowercase keys at the point of custom type validation.
Decisions
Should we changeblock_schema_spec
?Should we changemenu_schema_spec
?Should we changeschema_attribute_spec
?Answer to the above: No: we already treat built-in types as case insensitive, which would be too impactful to change. Keeping the type name validation scoped to custom types looks safe.
Consequences
We will manually fix custom types with uppercase letters (there are 4 of them).
All three current themes pass this new rule ✅
This will hook into the validation of custom types on the UI:
Also when linting a theme:
Co-authored-by: @eballantine