-
Notifications
You must be signed in to change notification settings - Fork 178
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
Create initial story JSON schema #12131
Conversation
Plugin builds for 868d956 are ready 🛎️!
|
@swissspidy On not storing the said values on elements (e.g.
Having a page element type is still relevant as it currently is. The same utils are used for creating a page as for other elements, it has its default element attributes etc. Not sure if storing |
"type": "object", | ||
"title": "The default background element", | ||
"$ref": "#/$defs/shapeElement", | ||
"$comment": "TODO: Move to story element or remove?" |
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.
Why remove? :)
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 was wondering whether it makes sense to store the default background element in the story data JSON in the first place, since this could in theory just be a const somewhere in the editor since it's static and never changes.
From what I can see we mainly need this information about the default background element when removing the background element (e.g. an image or video) and need to restore the default.
We can still have the isDefaultBackground
property to identify the default in the story JSON, should we ever need a data migration for it.
Does that make sense?
I'm checking now that the |
I didn't have anything in mind, but I can create a ticket to further discuss this idea 👍 The risk with a hardcoded list is that we forget to maintain it, but I think that becomes easier once we have strong TypeScript types for elements. Then one will get yelled at when adding a new unknown property anyway :-) |
Size Change: -761 B (0%) Total Size: 2.68 MB
ℹ️ View Unchanged
|
Context
See #12084
Summary
Found some bugs thanks to this:
343f355
Relevant Technical Choices
bin/
for nowajv-cli
for JSON schema validationajv-formats
to add support for things likeuuid
anddate-time
typesTo-do
backgroundOverlay
andfontWeight
from existing stories.Not sure how likely these exists on existing stories though.
showInLibrary
from ending up in the JSON data. Add a data migration accordingly & remove from schema.type: page
and we register a special "page" element type. Is that still relevant or outdated?current
,selection
, andstory
basedOn
property. Seems useless to keep, since this is only used when duplicating elements.User-facing changes
N/A
Testing Instructions
This PR can be tested by following these steps:
Reviews
Does this PR have a security-related impact?
No
Does this PR change what data or activity we track or use?
No
Does this PR have a legal-related impact?
No
Checklist
Type: XYZ
label to the PRFixes #12084