-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Add support for examples in OpenAPI block #2314
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
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.
xxxxxxxxxx
@@ -92,6 +93,12 @@ export function OpenAPISchemaProperty( | |||
className="openapi-schema-description" | |||
/> | |||
) : null} | |||
{schema.example ? ( |
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.
example
is not supposed to be markdown so why use markdown here? (https://swagger.io/docs/specification/adding-examples/)
It can result in problems, ex: if an example
contains a markdown string, it'll be processed there when the user expects to see the raw string.
We want to render a value instead of markdown text.
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.
Also the spacing with the description is not great, we should use a gap between the 2
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.
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.
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.
Also, argos is complaining for the right reasons as Examples are not present in argos. Can I approve it or do I need to update the images argos is using as a baseline? (first time working with argos where errors are justified)
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.
The font styling looks off to me. Have you checked that?
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.
@taranvohra Hmm, it looks fine to me. I can't see anything in my changes that would affect the font styling.
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.
The text color seems to stand about a bit too much. Is it black (#000)? Is it the same text color as the property name (iso-id
in your screenshot)
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.
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.
Idk why but this looks a bit better to me haha. It's subtle but it doesn't come across as fully black. Anyway, lgtm otherwise
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.
IMO it can't be merged in the current state and it requires more work:
- Properly support non-primitive values?
- should we represent with
JSON.stringify
? If yes, it'll not work well for XML/etc API - should we skip non-primitives using
typeof schema.example === 'string' || typeof schema.example === 'number' || typeof schema.example === 'boolean'
?
- should we represent with
- Should we handle
examples
as well by selecting the first example or the one matching the media-type?
@@ -14,6 +14,7 @@ interface OpenAPISchemaPropertyEntry { | |||
propertyName?: string; | |||
required?: boolean; | |||
schema: OpenAPIV3.SchemaObject; | |||
example?: string; |
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.
I don't understand why we need this prop. Isn't example
included in the schema
prop (https://github.com/kogosoftwarellc/open-api/blob/main/packages/openapi-types/index.ts#L166) ?
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.
Ok it looks like example
is for parameters and examples
is for schema fields. I think we should try to handle both the same way.
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.
It looks like you don't actually use this
example?: string; |
and you use schema.example
.
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.
@SamyPesse it looks like you got it reversed. example
is for schema fields, and examples
is for parameters
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.
I also think we should keep this PR just for the singular example
and not support examples
for now. What do you think?
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.
Yes, but it doesn't change the fact that this prop is actually not used:
example?: string; |
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.
removed
@@ -92,6 +93,9 @@ export function OpenAPISchemaProperty( | |||
className="openapi-schema-description" | |||
/> | |||
) : null} | |||
{schema.example ? ( | |||
<span className="openapi-schema-example">Example: {schema.example} </span> |
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.
We should use a <code>
or <pre>
around the value.
Also, how does it work if my example is not a primitive?
ex:
example:
propA: a
propB: b
My take is that it'll render [object Object]
which is bad.
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.
Are you doing the changes here?
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.
@@ -172,6 +172,10 @@ | |||
@apply prose-sm; | |||
} | |||
|
|||
.openapi-schema-example { | |||
@apply mt-2 text-base text-dark/10 dark:text-light/10; |
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.
Why are we using a larger text font than the description?
It doesn't look good in the screenshot.
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.
fixed. see the screenshot above
@@ -92,6 +93,9 @@ export function OpenAPISchemaProperty( | |||
className="openapi-schema-description" | |||
/> | |||
) : null} | |||
{schema.example ? ( |
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 condition is wrong.
If I have:
type: boolean
example: false
It'll not show
(or even empty string, etc).
We should check the typeof
and probably skip non-primitives.
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.
Doesn't the same problem exist for schema.description
right above this line as well? What if that is false?
I can of course do the typeof
check and skip non-primitives
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.
It's about the type. schema.description
is always a string and if it's empty we don't want to show an empty div.
schema.example
can be any value, depending on the schema.
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.
fixed
@@ -14,6 +14,7 @@ interface OpenAPISchemaPropertyEntry { | |||
propertyName?: string; | |||
required?: boolean; | |||
schema: OpenAPIV3.SchemaObject; | |||
example?: string; |
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.
Yes, but it doesn't change the fact that this prop is actually not used:
example?: string; |
@@ -92,6 +93,9 @@ export function OpenAPISchemaProperty( | |||
className="openapi-schema-description" | |||
/> | |||
) : null} | |||
{schema.example ? ( |
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.
It's about the type. schema.description
is always a string and if it's empty we don't want to show an empty div.
schema.example
can be any value, depending on the schema.
@@ -48,6 +48,7 @@ export function OpenAPISpec(props: { rawData: any; context: OpenAPIClientContext | |||
// Description of the parameter is defined at the parameter level | |||
// we use display it if the schema doesn't override it | |||
description: parameter.description, | |||
example: parameter.example, |
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.
Why do we need this? Isn't example
on the parameter.schema
itself.
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.
To maintain compatibility with Swagger 2.0 (in our docs we say we support 2.0). In 2.0, example
is not on parameter.schema
but on parameter
itself.
In 3.0, example
is on parameter.schema
, so the destructuring happening in the line below will take of it
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.
@@ -92,6 +93,9 @@ export function OpenAPISchemaProperty( | |||
className="openapi-schema-description" | |||
/> | |||
) : null} | |||
{schema.example ? ( | |||
<span className="openapi-schema-example">Example: {schema.example} </span> |
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.
Are you doing the changes here?
Same description as #2313