\n\nWhich looks nice, and is copyable in the left-hand side, however the right hand side syas [object Obvject] etc...\n\n---------------\n\nWhen specifying strings of json as the filters like this\n\n```\n 'filter': [\n '{\"limit\":10,\"order\":[\"timestamp DESC\"]}',\n '{\"where\":{\"timestamp\":{\"between\":[\"2024-12-01T00:00:00.000Z\",\"2024-12-01T23:59:59.999Z\"]}},\"order\":[\"timestamp DESC\"]}',\n '{\"where\":{\"correlationId\":\"abc123\"}}',\n ],\n```\n\nWe get an ugly left-hand side with escaping, and a nice right-hand side placeholder (no extra escaping)\n\n\u003Cimg width=\"1509\" height=\"220\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/a411efc1-f555-4d69-abb3-0dab9ee25450\" />\n\nUltimately in one of these cases, I would like the left-hand side to have a copyable string without escaping of \", and in the right-hand side it still be shown nicely in the placeholder.",[],301,"enzonotario","vitepress-openapi","open","Consistently handle example json escaping","2025-08-28T15:58:55Z","https://github.com/enzonotario/vitepress-openapi/issues/301",0.8189573,{"description":3180,"labels":3181,"number":3182,"owner":3172,"repository":3173,"state":3183,"title":3184,"updated_at":3185,"url":3186,"score":3187},"Hi! I was working on my current project, where I have a schema that produces this UI:\n\nhttps://github.com/user-attachments/assets/21f90ff1-fb58-4aff-86e5-249e453c829f\n\nThis little screencast aims to show that it's a bit non-obvious - especially for people who are just starting to explore the site with the spec and don't know how the UI works - that object properties are there. Long description with some markdown/emojis makes it seem like the description is all that exists under this property.\n\nIn contrast, when there's no description, it's pretty obvious that the properties are expandable:\n\n\u003Cimg width=\"390\" height=\"113\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/5b945a5a-e471-44b3-8f18-0e0219c8caa0\" />\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,"closed","[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.756471,{"description":3189,"labels":3190,"number":3194,"owner":3172,"repository":3173,"state":3183,"title":3195,"updated_at":3196,"url":3197,"score":3198},"### What would you like?\n\nI'd love it if there was an easy to use component that allowed displaying a link that looked like the nice fancy sidebars\n\nThis should be documented\n\n\n\nI'd like to be able to use this anywhere in text\n\n### Why is this needed?\n\n_No response_\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3191],{"name":3192,"color":3193},"enhancement","a2eeef",222,"Reusable component for linking to specs / api pages","2025-06-30T01:23:53Z","https://github.com/enzonotario/vitepress-openapi/issues/222",0.78988206,{"description":3200,"labels":3201,"number":3205,"owner":3172,"repository":3173,"state":3183,"title":3206,"updated_at":3207,"url":3208,"score":3209},"### What would you like?\n\nHow can I create my own custom components to implement my own needs?\n\n### Why is this needed?\n\n_No response_\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3202],{"name":3203,"color":3204},"question","d876e3",229,"How can I custom the render component","2025-05-31T22:29:15Z","https://github.com/enzonotario/vitepress-openapi/issues/229",0.8026903,{"description":3211,"labels":3212,"number":1643,"owner":3172,"repository":3213,"state":3183,"title":3214,"updated_at":3215,"url":3216,"score":3217},"Buenas! Qué tal?\r\n\r\nEstoy viendo un error en la cotización del Peso Chileno, probablemente relacionado con otro issue cerrado que leí recién, donde el valor hay que dividirlo por 100 para que esté bien. Esto es lo que está mostrando ahora:\r\n\r\n\r\n\r\nMil gracias por API!!\r\nSaludos!\r\n\r\n",[],"esjs-dolar-api","Error en la cotización del Peso Chileno","2024-09-06T21:40:13Z","https://github.com/enzonotario/esjs-dolar-api/issues/29",0.8194945,{"description":3219,"labels":3220,"number":3221,"owner":3172,"repository":3173,"state":3183,"title":3222,"updated_at":3223,"url":3224,"score":3225},"I believe spec such as this is valid and OK.\n\nBasically having a schema object, that has a property of type string, and then using oneOf to be abe to define extra information about the strings.\n\n```\n \"notificationTrigger\": {\n \"properties\": {\n \"name\": {\n \"type\": \"string\"\n },\n \"type\": {\n \"type\": \"string\",\n \"oneOf\": [\n { \"const\": \"lowBat\", \"title\": \"Low Battery\", \"description\": \"Triggered when battery level is low.\" },\n { \"const\": \"button\", \"title\": \"Button Press\", \"description\": \"Triggered on a button press.\" },\n \n```\n\nI believe a relevant link from the spec would be https://spec.openapis.org/oas/v3.1.1.html#model-with-annotated-enumeration\n\nHowever the components currently render this incorrectly.\n\n\u003Cimg width=\"670\" height=\"396\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/267cff6d-9c0a-4bd7-8a8e-734588fb775b\" />",[],288,"Support rendering model-with-annotated-enumeration in Request Body schema","2025-08-11T22:29:43Z","https://github.com/enzonotario/vitepress-openapi/issues/288",0.8214946,{"description":3227,"labels":3228,"number":3230,"owner":3172,"repository":3173,"state":3183,"title":3231,"updated_at":3232,"url":3233,"score":3234},"### What would you like?\r\n\r\nList of tags underneath the title\r\n\r\n### Why is this needed?\r\n\r\nWould be handy with tags pages, if one doesn't show tags in the sidebar (without `itemsByTags`)\r\n\r\n### How could it be implemented?\r\n\r\nI use following workaround\r\n\r\n```vue\r\n\u003COAOperation :operationId=\"operationId\" :isDark=\"isDark\" >\r\n \u003Ctemplate #description=\"description\">\r\n \u003Cdiv>\r\n \u003CBadge type=\"info\" v-for=\"tag in operation.tags\">\r\n \u003C!-- hardocde prefix, tell me if you know better way -->\r\n \u003Ca :href=\"`/tags/${tag}`\">{{ tag }}\u003C/a>\r\n \u003C/Badge>\r\n \u003C/div>\r\n \u003C/template>\r\n\u003C/OAOperation>\r\n```\r\n\r\nBut would be nice to have\r\n\r\n```ts\r\nuseTheme({\r\n operation: {\r\n slots: ['tags']\r\n }\r\n})\r\n```\r\n\r\n### Other information\r\n\r\nRelated: it would be nice to have more compact representation of endpoints lists for tags pages. For now I use\r\n\r\n```ts\r\nimport { useTheme } from 'vitepress-openapi'\r\nuseTheme({\r\n operation: {\r\n slots: [\r\n 'header',\r\n 'path',\r\n 'description',\r\n ],\r\n cols: 2,\r\n },\r\n})\r\n```\r\n\r\nWhich looks a bit strange",[3229],{"name":3192,"color":3193},120,"Add tags slot","2024-12-02T03:07:06Z","https://github.com/enzonotario/vitepress-openapi/issues/120",0.8231068,{"description":3236,"labels":3237,"number":3238,"owner":3172,"repository":3173,"state":3183,"title":3239,"updated_at":3240,"url":3241,"score":3242},"Tried on 0.0.3-alpha.63, and 0.0.3-alpha.79 (latest release)\n\nI have a header such as this defined\n\n```\n {\n \"description\": \"Optionally provide parameters as a JSON object in this header. If both query params and X-Query overlap, a 400 error is returned.\",\n \"example\": \"{\\\"id\\\":\\\"1\\\"}\",\n \"in\": \"header\",\n \"name\": \"X-Query\",\n \"schema\": {\n \"type\": \"string\"\n }\n }\n```\n\nBut also a param like this\n\n```\n {\n \"description\": \"Filter by ID (comma separated for multiple values)\",\n \"in\": \"query\",\n \"name\": \"id\",\n \"schema\": {\n \"description\": \"Filter by ID (comma separated for multiple values)\",\n \"example\": \"1\",\n \"form\": \"id\",\n \"type\": \"string\"\n }\n },\n```\n\nBoth of these examples are used by the UI component, and provided in the default try it requests.\nHowever this means that the request will always fail, as the examples conflict with each other.\nHowever, I want to be able to provide real examples to both of these...\n\nI think that either\n1) Examples should not be used in the default try it param\n2) There should be an option to disable it?",[],221,"example should not always be used as the default for the UI","2025-05-18T01:43:41Z","https://github.com/enzonotario/vitepress-openapi/issues/221",0.8242499,{"description":3244,"labels":3245,"number":3246,"owner":3172,"repository":3173,"state":3183,"title":3247,"updated_at":3248,"url":3249,"score":3250},"### Current behavior\n\nMy security scheme is as follows:\n`\"securitySchemes\": {\n \"APIKeyQuery\": {\n \"type\": \"apiKey\",\n \"in\": \"query\",\n \"name\": \"api_key\"\n }`\n\nWhen clicking \"Try it out\", the browser sends:\n```\nGET /api/endpoint\nHeaders: Api_key: example_key\n```\n\n### Desired behavior\n\n`GET /api/endpoint?api_key=example_key`\n\n### Steps to reproduce\n**Environment:**\n- vitepress-openapi@0.1.7\n- \"vitepress\": \"^1.6.3\"\n- browser: any\n\nadd `\"securitySchemes\": {\n \"APIKeyQuery\": {\n \"type\": \"apiKey\",\n \"in\": \"query\",\n \"name\": \"api_key\"\n }` to your openapi.json\nand see that it goes to headers instead of query\n\n### Logs and Error Messages\n\nThis causes API calls to fail since our server expects the API key as a query parameter, making the interactive documentation unusable.\n\n### Other Information\n\nCan you please fix this?",[],294,"API key query parameters sent as headers instead","2025-08-13T01:15:02Z","https://github.com/enzonotario/vitepress-openapi/issues/294",0.8326574,{"description":3252,"labels":3253,"number":3255,"owner":3172,"repository":3173,"state":3183,"title":3256,"updated_at":3257,"url":3258,"score":3259},"### What would you like?\n\nI would like my users to be able to download the spec directly from the one page of `OASpec`\n\n### Why is this needed?\n\nOften customers will want to generate a client for an API, it's an easy way for them to find the source openapi file.\n\n### How could it be implemented?\n\nI would suggest a `Download spec` link under the title of the API.\n\n### Other information\n\n_No response_",[3254],{"name":3192,"color":3193},231,"Add download button","2025-06-20T23:18:13Z","https://github.com/enzonotario/vitepress-openapi/issues/231",0.8329961,["Reactive",3261],{},["Set"],["ShallowReactive",3264],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fznyZ4MohxOtNmcLXlM4GjHFBoQUsDLeeDEWDTQlaAF0":-1},"/enzonotario/vitepress-openapi/290"]