-
Notifications
You must be signed in to change notification settings - Fork 299
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
Support for discriminator objects inside schemas #170
Comments
Well, at RapiDoc, we wont be supporting discriminator at least for the foreseeable future. We did try to implement it in the past, but were not able to cleanly address certain complex cases involving other schema composition rules such as Redoc do supports discriminator but their implementation is buggy too. |
Do you happen to have any examples regarding those complex composition use cases, or in what ways Redoc's implementation turns out to be buggy? I understand your point on how this is a somewhat niche feature (as far as OpenAPI goes, anyway) and that the returns on user experience wouldn't be all that significant, but I'm curious to know about the implementation issues and pitfalls. |
a quick search of Redocly/redoc#1088 there are more, I am just listed few of them |
Would a pull request be welcome for this? |
https://github.com/mrin9/RapiDoc/blob/9c5401f06f3f1fe162b1a80a540b45da26ae74db/docs/specs/petstore_extended.yaml#L781-L786
In the extended petstore OpenAPI example, the
Pet
schema has apetType
tag that is used as a discriminator to determine which of the 3 variants of pet is actually used. Redoc supports it (see thePOST /pet
route) and adjusts the properties presented in the UI based on the value of the discriminator property. RapiDoc does not currently appear to support this, at least not in the way the above example does it. For the record, Swagger UI doesn't support it either, despite this being a standard OpenAPI property).There was recently a discussion from the OpenAPI team to deprecate
discriminator
(see OAI/OpenAPI-Specification#2143), but the consensus now seems to be that it does have a clear purpose (namely: identify tagged unions) and should be kept.The text was updated successfully, but these errors were encountered: