\n\nBut in the case of a rich description - which is visible by default and draws attention away from the relatively small \"expand\" button icon on the top - a user who reads the description might reasonably assume that it's the only content. They may not think, \"Hmm, I read the description, but there must be properties - let me look for some element that will let me show them!\"\n\n## Suggestions:\n\n### Option 1:\n\nHide descriptions for objects when in Collapsed state, show only when Expanded:\n\nhttps://github.com/user-attachments/assets/40ead49f-6023-4cbb-9a7b-8e5a5c96b952\n\n### Option 2:\n\nShow a small hint after the description, like a verbose \"Expand\" text button or a similar UI element (only shown when it's an array/object and has a description):\n\nhttps://github.com/user-attachments/assets/c8a31a05-6b54-400d-84a9-b126b9762b1e\n\n---\n\nLet me know what you think, @enzonotario! Do you like any of the proposed options, or do you have some other idea of how to address this?",[],271,"[Discussion] When an object has a description, it's not obvious that its properties are expandable","2025-07-21T01:18:22Z","https://github.com/enzonotario/vitepress-openapi/issues/271",0.80148774,{"description":3060,"labels":3061,"number":3065,"owner":3023,"repository":3024,"state":3025,"title":3066,"updated_at":3067,"url":3068,"score":3069},"### Current behavior\n\n\n\n### Desired behavior\n\nEither the text should wrap, or just be displayed in a better way\n\n### Reproduction\n\n_No response_\n\n### Steps to reproduce\n\n```\n \"securitySchemes\": {\n \"ApiKeyAuth\": {\n \"in\": \"header\",\n \"name\": \"Authorization\",\n \"type\": \"apiKey\",\n\"description\": \"API Key for authentication. Retrieval from either API version login routes, or other authentication token type. See \u003Ca href='/apis/authentication'>Authentication\u003C/a> for more details.\",\n\"example\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOjEsImlhdCI6MTY3Mjc2NjAyOCwiZXhwIjoxNjc0NDk0MDI4fQ.kCak9sLJr74frSRVQp0_27BY4iBCgQSmoT3vQVWKzJg\"\n }\n }\n```\n\n### Logs and Error Messages\n\n_No response_\n\n### Other Information\n\n_No response_",[3062],{"name":3063,"color":3064},"bug","d73a4a",236,"Long Authorization example doesnt display nicely","2025-06-22T12:55:43Z","https://github.com/enzonotario/vitepress-openapi/issues/236",0.8060854,{"description":3071,"labels":3072,"number":3074,"owner":3023,"repository":3024,"state":3025,"title":3075,"updated_at":3076,"url":3077,"score":3078},"### What would you like?\n\nI wonder if it is possible to implement path based sidebar. For example, we have\r\n\r\n```\r\n/api/v1/products CRUD\r\n/api/v1/orders CRUD\r\n```\r\n\r\nSidebar would look like\r\n\r\n```\r\n/api/v1\r\n ├ products\r\n | ├ PUT\r\n | ├ GET\r\n | ├ POST\r\n | └ DELETE\r\n └ orders\r\n ├ PUT\r\n ├ GET\r\n ├ POST\r\n └ DELETE\r\n```\r\n\r\n**Note**: empty folders are collapsed\r\n\n\n### Why is this needed?\n\nI want to use more than one tag per endpoint. But in this case sidebar looks strange. Maybe there is a way to organize sidebar better even if there are multiple tags...\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3073],{"name":3020,"color":3021},119,"Path based sidebar","2024-12-12T03:25:21Z","https://github.com/enzonotario/vitepress-openapi/issues/119",0.8099664,{"description":3080,"labels":3081,"number":1987,"owner":3023,"repository":3024,"state":3025,"title":3083,"updated_at":3084,"url":3085,"score":3086},"My rendered component looks something like this\r\n\r\n\r\n\r\nHowever the define route doesnt require authentication\r\n\r\n```\r\n \"/users/login\": {\r\n \"post\": {\r\n \"description\": \"lalala.\",\r\n \"requestBody\": {\r\n \"content\": {\r\n \"application/json\": {\r\n \"schema\": {\r\n \"$ref\": \"#/components/schemas/LoginRequest\"\r\n }\r\n }\r\n },\r\n \"description\": \"Login\",\r\n \"required\": true\r\n },\r\n \"responses\": {\r\n \"200\": {\r\n \"content\": {\r\n \"application/json\": {\r\n \"schema\": {\r\n \"$ref\": \"#/components/schemas/LoginResponse\"\r\n }\r\n }\r\n },\r\n \"description\": \"OK\"\r\n },\r\n },\r\n \"summary\": \"Login\",\r\n \"tags\": [\r\n \"users\"\r\n ]\r\n }\r\n },\r\n```\r\n\r\nOther endpoints do specify it as a requirement\r\n\r\n```\r\n \"security\": [\r\n {\r\n \"ApiKeyAuth\": []\r\n }\r\n ],\r\n```\r\n\r\nAnd it is defined as a schema in the spec\r\n\r\n```\r\n \"securitySchemes\": {\r\n \"ApiKeyAuth\": {\r\n \"in\": \"header\",\r\n \"name\": \"Authorization\",\r\n \"type\": \"apiKey\"\r\n }\r\n }\r\n```\r\n\r\nBut it should not be rendered by default unless they are deinfed in a top level `security` section\r\n\r\nSee https://swagger.io/docs/specification/authentication/ `Step 2.`",[3082],{"name":3063,"color":3064},"securitySchemes should only be applied to routes that require it","2024-09-14T16:10:12Z","https://github.com/enzonotario/vitepress-openapi/issues/36",0.81211567,{"description":3088,"labels":3089,"number":3090,"owner":3023,"repository":3024,"state":3025,"title":3091,"updated_at":3092,"url":3093,"score":3094},"I noticed this while playing with the auth tokens, however it probably applies to all fields.\n\nIt would be really nice while clicking into a field that has `.` chars in it, if by default it would select the whole field?\n\n\n\nFor this token, it breaks on the 2 `.` sections",[],247,"Change field selection boundaries","2025-06-26T22:32:02Z","https://github.com/enzonotario/vitepress-openapi/issues/247",0.81949157,{"description":3096,"labels":3097,"number":3099,"owner":3023,"repository":3024,"state":3025,"title":3100,"updated_at":3101,"url":3102,"score":3103},"### What would you like?\n\nThe current version generates \"static\" code for each language, based only on the url and method. Unfortunately, the url is simply: `const url = props.baseUrl + props.path`. This has the issue that any path parameters are left as-is in the code.\r\n\r\nIt would be great if the sample code could be updated to include the variables in the \"try it\" box. This way the code sample would be \"complete\". I _think_ this would be done in much the same was as the `OACodeBlock` currently computes the URL for curl\n\n### Why is this needed?\n\nIf you copy-and-paste the code sample as-is, you will end up with an invalid URL if there are path parameters.\r\n\r\nAlso, it would be nice to mix-and-match such that you can _remove_ the try it portion of the playground, but keep the sample code. This way people can \"build\" a request in their language of choice based on the variables form.\n\n### How could it be implemented?\n\nI _think_ you would need to extract (or just duplicate?) the code used to compute the curl information:\r\n\r\n```\r\nconst curl = computed(() => {\r\n const headers = request.value.headers\r\n if (!headers?.['Content-Type']) {\r\n headers['Content-Type'] = 'application/json'\r\n }\r\n\r\n return fetchToCurl({\r\n method: props.method.toUpperCase(),\r\n url: request.value.url,\r\n headers,\r\n body: request.value.body ? formatJson(request.value.body) : null,\r\n })\r\n})\r\n```\r\n\r\nThen pass this as a parameter to `generateCodeSamples` so that it can generate each code sample appropriately.\n\n### Other information\n\nIt would also be _awesome_ to select _which_ languages you want to support, and possibly even some way to provide the template for each language. I realize this is above-and-beyond, but something to think about if you're changing this.",[3098],{"name":3020,"color":3021},92,"Modify Sample Code Based on Variables","2024-11-15T02:40:07Z","https://github.com/enzonotario/vitepress-openapi/issues/92",0.82164854,{"description":3105,"labels":3106,"number":1024,"owner":3023,"repository":3024,"state":3025,"title":3108,"updated_at":3109,"url":3110,"score":3111},"Currently I have something like this on a single markdown page...\r\n\r\n```\r\n\u003Cscript setup lang=\"ts\">\r\nimport { useRoute, useData } from 'vitepress'\r\nimport { useSidebar, useOpenapi } from 'vitepress-theme-openapi'\r\nimport spec from '../swagger/v2.json' with { type: 'json' }\r\nconst openapi = useOpenapi()\r\nopenapi.setSpec(spec)\r\nconst route = useRoute()\r\nconst { isDark } = useData()\r\n\u003C/script>\r\n\r\n\u003COAOperation operationId=\"post-users-login\" method=\"post\" :isDark=\"isDark\" />\r\n\u003COAOperation operationId=\"post-users-refreshToken\" method=\"post\" :isDark=\"isDark\" />\r\n```\r\n\r\nFurther down the page I would like to include a component rendered from the `../swagger/v1.json` spec, however I believe with the current setup that will not be possible.\r\n\r\nUltimately I think this will require passing the openapi into the components? :)",[3107],{"name":3020,"color":3021},"Enable rendering components for multiple specs on a single page.","2024-09-28T15:44:23Z","https://github.com/enzonotario/vitepress-openapi/issues/21",0.8271349,["Reactive",3113],{},["Set"],["ShallowReactive",3116],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fwn1v7wrF4gLDIinn_5Ez2jweFkm9UI-EJh0CnNcpogY":-1},"/enzonotario/vitepress-openapi/221"]