Best exposition, I have heard. I am new to JSON schemas but learned from this presentation, even though some stuff was over my head. Do you have a github repository with these examples
12:19 I guess the source of this usage is `json-schema-to-typescript` prepending the index signature to the interfaces without this keyword by default. To counter this behaviour the user either has to pass an argument on each CLI call or change the default config value. But it's not semantically wrong either. Majority of use-cases for json schema is to describe the serializable structure of the request body for an endpoint, which tends to be rigid if only for the purpose of caching. But these structures don't exist in a vacuum, they have to be used within the consumer environment and for that their interface has to be extensible for the internal usage, but not their json representation.
So $dynamicRef and $dynamicAnchor are basically a true inheritance & overriding patterns? Like everytime we just use $ref we can only add properties/constraints (and those should be non-conflicting)? In other words the base schema defines the $dynamicRef so that it indicates that you (as the client) can override the behavior. One question though: why would be use $dynamicAnchor inside the base schema? Is it required? I mean, if we don't define a matching $dynamicAnchor then the schema will be incomplete?
Nice content, keep it up
Best exposition, I have heard. I am new to JSON schemas but learned from this presentation, even though some stuff was over my head. Do you have a github repository with these examples
12:19
I guess the source of this usage is `json-schema-to-typescript` prepending the index signature to the interfaces without this keyword by default. To counter this behaviour the user either has to pass an argument on each CLI call or change the default config value.
But it's not semantically wrong either. Majority of use-cases for json schema is to describe the serializable structure of the request body for an endpoint, which tends to be rigid if only for the purpose of caching. But these structures don't exist in a vacuum, they have to be used within the consumer environment and for that their interface has to be extensible for the internal usage, but not their json representation.
So $dynamicRef and $dynamicAnchor are basically a true inheritance & overriding patterns? Like everytime we just use $ref we can only add properties/constraints (and those should be non-conflicting)? In other words the base schema defines the $dynamicRef so that it indicates that you (as the client) can override the behavior. One question though: why would be use $dynamicAnchor inside the base schema? Is it required? I mean, if we don't define a matching $dynamicAnchor then the schema will be incomplete?