Support generics

[goodmind]

Can you support generics? Like generating from this:

{
   "title": "TGenericNumber",
   "type": { "$ref": "#/definitions/iarg", "generics": ["number", "string"] },
   "definitions": {
      "iarg": {
         "title": "IArg<T, R>",
         "properties": {
            "key": { "type": "T" },
            "value": { "type": "R" }
         }
      }
   }
}

to this:

export interface IArg<T, R> { key: T, value: R };
export type TGeneric = IArg<number, string>;

[bcherny]

This is an interesting idea. I guess there are 2 parts:

1. Inferring that property types are generic - We can either:
   a. Assume that types that begin with a capital letter are generic
   b. Use an explicit JSON-Schema extension, eg. "genericType": "T"
   c. Don't special case, and let the consumer handle it (as in your example)
2. Binding concrete types to generic types:
   a. Use an explicit JSON-Schema extension (as in your example)
   b. ???

[goodmind]

Explicit is always better than implicit, but for first part I was assuming that it will infer types from title <T, R>

[bcherny]

Inferring from title is too unstructured for my taste, and makes parts 1 and 2 above asymmetrical. Also, someone might for some reason have "IArg<T, R>" as a title, but not intend it as a generic interface. I'd go for explicit all the way through (options 1b and 2a). What do you think?

[goodmind]

maybe you are right

[goodmind]

@bcherny Yes, you are right explicit is better here too

[joseSantacruz]

Any update on this new feature would be great to have and also add conditionals types

[bcherny]

@joseSantacruz What’s your use case for generic and conditional types in JSON-Schema?

[haggholm]

My use case (and the reason for my fork) is opaque containers. For example, our application has a lot of encrypted data, so our API frequently sends something of type CryptoContainer with predictable fields for ciphertext, algorithm options, &c., but this doesn’t provide information about what is encrypted. Hence, I added generic parameters like CryptoContainer<T> so that, though this won’t be enforced by JSON schema validation, at least the server and client can agree on the protocol.

[Guchman]

That's necessary for container-contracts: events, commands, etc. We faced same problem with protobuffs and there is only workaround to use something like Any, but I don't have an idea how to do same with json-schema.
It's really hard to support DTOs like CutstomerEvent, ApplicationEvent, PaymentEvent instead of Event, for example Event.

[john30]

a rather simple way of allowing use of generics is to patch the regex in toSafeString() in src/utils.ts to also allow "<" and ">" being part of TS identifier and then use e.g.

title: Typename<Generic>

[ShoeBoom]

there is $dynamicAnchor and $dynamicRef

https://github.com/orgs/json-schema-org/discussions/230

Not sure how complex this would be to support tho