Generate an in-transit tree #39
Conversation
chee
requested review from
serena97 and
cebirmingham
and removed request for
a team
| picture?: ImageSetPicture | ||
| external picture: ImageSetPicture |
There was a problem hiding this comment.
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.
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.
this describes the new external property modifer. which works like the readonly property modifier in typescript, except it only exists in this readme
lol. today is March 15th. |
There was a problem hiding this comment.
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
bodynode need to have atransit?: booleanfield?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.transitnamespace then we're gucci, right?