-
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
Generate an in-transit tree #39
Conversation
picture?: ImageSetPicture | ||
external picture: ImageSetPicture |
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.
here we mark the picture as external
// in the full tree, externals are mandatory | ||
const full = code.replace(/^(\s+)external (.+)$/gm, "$1$2") | ||
// in the transit tree, externals must not be present | ||
const transit = code.replace(/^\s+external (.+:).+$/gm, "") |
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.
this is the entire logic for how the two namespaces are generated. remove the external
modifier for the full tree, remove the entire property for the transit tree
…pescript documentation
The `external` property modifier indicates that the specified field is absent | ||
when the `content-tree` is in | ||
[**transit**](#what-does-it-mean-to-be-in-transit), and required when the | ||
**content-tree** is at rest. |
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.
this describes the new external
property modifer. which works like the readonly
property modifier in typescript, except it only exists in this readme
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.
Neat!
I don't think we need any form of runtime validation in the spec IMO. If consumers wish to, they can use something like zod
to validate against the generated types. Customer Products currently does that for the entire C&M response, so it should work for free once they designate bodyTree
of having type ContentTree.transit.body
.
Probably want a 👍 from one of the other teams here as well
all works well. one remaining question:
do we need a runtime way of distinguishing one tree from another?
does the
body
node need to have atransit?: boolean
field?i don't think it does... i don't think we need that.
if we generate the
[insert whatever we use to validate on c&m]
types from theContentTree.transit
namespace then we're gucci, right?