\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.80148256,{"description":3180,"labels":3181,"number":3182,"owner":3172,"repository":3173,"state":3174,"title":3183,"updated_at":3184,"url":3185,"score":3186},"So, following on from https://github.com/enzonotario/vitepress-openapi/issues/237#issuecomment-2994204686\n\nThis \"issue\" is rather a place to collect my thoughts and discuss, potentially some of these ideas are bad, but its the combination of thoughts given the `xxx` confusion I had, + pulling in thoughts from other tooling I have used.\n\n---\n\n\n\nThe display of `xxx` is unclear to me in terms of what it is trying to communicate.\nIt could be one of these things\n - xxx is the example, a placeholder for you to enter something into\n - It could be representing the fact that a value is there, but we dont want to show you (like `***` for passwords)\n - It could be the actual value saved in local storage? waiting for you to update it?\n\nWhen loading first time and making a request, I actually saw that it made a request with a literal `xxx`\n\n\n\nNot sure if this is something I had entered though?\n\nIt was indeed stored in local storage (and the UI didn't really help me figure that out...)\n\n\n\nDeleting the key from local storage, and I then correctly see the example appear in the latest version\n\n\n\nAs a result, im not sure if https://github.com/enzonotario/vitepress-openapi/issues/237 even was an issue, or rather just I had no idea where the `xxx` was coming from?\n\nSo, I would propose......\n\n**1)When key is stored and coming form local storage, keep it editable**\n\nCurrently when its coming form local storage, it is the placeholder for the field..\n\n\n\nThis makes it appear exactly like the example, and examples else where and thus is easily confused.\n\nI see other API sandboxes just keep / load the field into the text box and leave it there, so perhaps just do that?\n\n**2)Hover text for field saying it is stored between sessions in local storage?**\n\nAgain, a subtle way to make it easier for folks to understand what it going on?\n\n**3)Provide a way to clear from local storage**\n\nPerhaps a small clear button next to the APIKey name?\n\n\n\nMaybe there should even be a save button here rather than doing it automatically?\n\nPerhaps all of what I have said and am saying should be other in the other component?\n\n\n\n**4) Provide an optional button next to token field, to take a user to a page to setup the api key?**\n\nThis could be a custom dedicated page with custom content.\nIt thus could be as simple as just a page with instructions, and also a text box and save button that would put the key in local storage?\nIt could also just be a popup?\n\nPerhaps a default component for use on such as page could be used that takes the key and puts it in the right place in local storage?\n\nAnd perhaps another way of default option that could be provided would be a link to the route page that would generate the token, such as in my case http://localhost:8093/apis/v2/post-users-login\nOnce making the request and getting a response, next to the response would be a button to say \"set as API key\" or such?\nSo this would require some additional options on the route component?\n\nPerhaps something in one of these 3 green places?\n\n",[],246,"Ideas around Authorization saving and population","2025-06-23T08:01:09Z","https://github.com/enzonotario/vitepress-openapi/issues/246",0.8067145,{"description":3188,"labels":3189,"number":3190,"owner":3172,"repository":3173,"state":3191,"title":3192,"updated_at":3193,"url":3194,"score":3195},"1、In the file upload scenario, when the browser initiates a request, the header Content-Type does not contain a boundary parameter; normally, when making a request in Postman with a content-type of multipart/form-data, the boundary parameter is automatically included\nthe openai.json:\n\u003Cimg width=\"568\" height=\"832\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/e6ec6b35-60cb-4632-bc8b-63fc1cd7ae19\" />\n\nthe postman request:\n\u003Cimg width=\"1356\" height=\"550\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/d8f101f6-ff4f-4106-bd8f-016970e70c1e\" />\n\n\u003Cimg width=\"1091\" height=\"691\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/92855ba7-fb6c-4526-8db2-5698519cd093\" />\n\n\n\n2、When I call the download file interface, the \"download files\" button is not responding。\n\n\u003Cimg width=\"392\" height=\"274\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/05b06400-49b1-4885-a710-27fc7be3c34e\" />",[],279,"closed","upload and download issues","2025-08-12T23:37:59Z","https://github.com/enzonotario/vitepress-openapi/issues/279",0.8014207,{"description":3197,"labels":3198,"number":3199,"owner":3172,"repository":3173,"state":3191,"title":3200,"updated_at":3201,"url":3202,"score":3203},"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,"[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.8014907,{"description":3205,"labels":3206,"number":3210,"owner":3172,"repository":3173,"state":3191,"title":3211,"updated_at":3212,"url":3213,"score":3214},"### 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.",[3207],{"name":3208,"color":3209},"enhancement","a2eeef",92,"Modify Sample Code Based on Variables","2024-11-15T02:40:07Z","https://github.com/enzonotario/vitepress-openapi/issues/92",0.80886006,{"description":3216,"labels":3217,"number":1612,"owner":3172,"repository":3173,"state":3191,"title":3219,"updated_at":3220,"url":3221,"score":3222},"So, hvaing this in the front matter\r\n\r\n```\r\naside: true\r\noutline: true\r\n``` \r\n\r\nout of the box results in a very verbose set of headings.\r\n\r\nIt might be nice for the default heading levels (or tags used) to present themselves a little nicer in the asied outline!\r\n\r\n\r\n",[3218],{"name":3208,"color":3209},"Allow choosing component heading levels","2024-09-19T22:35:35Z","https://github.com/enzonotario/vitepress-openapi/issues/37",0.81892973,{"description":3224,"labels":3225,"number":3226,"owner":3172,"repository":3173,"state":3191,"title":3227,"updated_at":3228,"url":3229,"score":3230},"### What would you like?\n\nVitepress has the ability to define [custom components](https://vitepress.dev/guide/extending-default-theme#registering-global-components) which can later on be used across the documentation.\r\n\r\nIt would be nice if we could use such custom components in the generated api operations.\r\n\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_",[],89,"(Custom Slots usage) Allow using custom components in operations","2024-10-16T22:01:29Z","https://github.com/enzonotario/vitepress-openapi/issues/89",0.8211067,{"description":3232,"labels":3233,"number":3235,"owner":3172,"repository":3173,"state":3191,"title":3236,"updated_at":3237,"url":3238,"score":3239},"### What would you like?\n\nI'd like to be able to render the openapi specification with a signle column layout. It would be nice if it is configurable in the parameters of the components like OASpec or globally in the theme config. In addition to that, it would also be nice if the different child components could be enabled/disabled (i.e. turn off samples). \n\n### Why is this needed?\n\nI want this because the standard theme does not have a lot of content width, Having a two column layout looks crowded and sometimes the content is wrapped. Having all the child components below each other with a single column layout would bring more clarity to the rendered documentation.\n\n### How could it be implemented?\n\n_No response_\n\n### Other information\n\n_No response_",[3234],{"name":3208,"color":3209},91,"Single column layout","2024-10-27T14:41:53Z","https://github.com/enzonotario/vitepress-openapi/issues/91",0.82346386,{"description":3241,"labels":3242,"number":93,"owner":3172,"repository":3243,"state":3191,"title":3244,"updated_at":3245,"url":3246,"score":3247},"In the file upload scenario, the --header Content-Type does not have a boundary parameter;\nWhen downloading files, the \"download files\" button is not responding\n\n\u003Cimg width=\"522\" height=\"448\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/ac3e96e3-4381-4fc4-9785-ba1841730101\" />\n",[],"vitepress-openapi-starter","File upload and download issues","2025-07-24T12:20:31Z","https://github.com/enzonotario/vitepress-openapi-starter/issues/1",0.8235857,{"description":3249,"labels":3250,"number":3252,"owner":3172,"repository":3173,"state":3191,"title":3253,"updated_at":3254,"url":3255,"score":3256},"### Current behavior\n\n\n\n### Desired behavior\n\nI'm not sure what the desired behaviour should be here.\nHowever the `xxx` is seemingly hardcoded in the components currently, and i half would have expected the example to override this based on the behaviours of other parameter and variables examples in the playground.\n\nIt might even be nicer to just have the default auth actually always be an empty string rather than xxx?\n\n### Reproduction\n\n_No response_\n\n### Steps to reproduce\n\nJust provide an example, and see it not appear in the playground...\n\n### Logs and Error Messages\n\n_No response_\n\n### Other Information\n\n_No response_",[3251],{"name":3208,"color":3209},237,"Authorization example not shown in playground, inconsistent with other examples?","2025-06-22T12:55:44Z","https://github.com/enzonotario/vitepress-openapi/issues/237",0.8240911,["Reactive",3258],{},["Set"],["ShallowReactive",3261],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fTi8mSu5spQkcm9chd48E4nQlE5Z7AruYFXQoPLgYDzA":-1},"/enzonotario/vitepress-openapi/247"]