\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.8014907,{"description":3036,"labels":3037,"number":3041,"owner":3019,"repository":3020,"state":3030,"title":3042,"updated_at":3043,"url":3044,"score":3045},"### 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.",[3038],{"name":3039,"color":3040},"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":3047,"labels":3048,"number":1596,"owner":3019,"repository":3020,"state":3030,"title":3050,"updated_at":3051,"url":3052,"score":3053},"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",[3049],{"name":3039,"color":3040},"Allow choosing component heading levels","2024-09-19T22:35:35Z","https://github.com/enzonotario/vitepress-openapi/issues/37",0.81892973,{"description":3055,"labels":3056,"number":3057,"owner":3019,"repository":3020,"state":3030,"title":3058,"updated_at":3059,"url":3060,"score":3061},"### 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":3063,"labels":3064,"number":3066,"owner":3019,"repository":3020,"state":3030,"title":3067,"updated_at":3068,"url":3069,"score":3070},"### 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_",[3065],{"name":3039,"color":3040},91,"Single column layout","2024-10-27T14:41:53Z","https://github.com/enzonotario/vitepress-openapi/issues/91",0.82346386,{"description":3072,"labels":3073,"number":3075,"owner":3019,"repository":3020,"state":3030,"title":3076,"updated_at":3077,"url":3078,"score":3079},"### 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_",[3074],{"name":3039,"color":3040},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,{"description":3081,"labels":3082,"number":3083,"owner":3019,"repository":3020,"state":3030,"title":3084,"updated_at":3085,"url":3086,"score":3087},"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.82509756,{"description":3089,"labels":3090,"number":3092,"owner":3019,"repository":3020,"state":3030,"title":3093,"updated_at":3094,"url":3095,"score":3096},"### What would you like?\n\nThe ability to change the default url/port for the \"Try It Out\" button. \n\n### Why is this needed?\n\nThe API I'm building has different ports for different things. In my specific case, the current behavior does not invoke my api. \n\n### How could it be implemented?\n\nCould we possibly have an additional env variable that overwrites the default behavior?\n\n### Other information\n\n_No response_",[3091],{"name":3039,"color":3040},127,"Overwrite \"Try It Out\" url","2024-12-21T01:51:19Z","https://github.com/enzonotario/vitepress-openapi/issues/127",0.82825047,{"description":3098,"labels":3099,"number":3104,"owner":3019,"repository":3020,"state":3030,"title":3105,"updated_at":3106,"url":3107,"score":3108},"### What would you like?\n\nRight now It generate such page \r\n\r\n\r\nwould like to remove Default on the side and move the table of content to the left\r\n\r\nOr alternatively, if I could change the name and add a description so the left do not feel emptu\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_",[3100,3101],{"name":3039,"color":3040},{"name":3102,"color":3103},"question","d876e3",109,"Any way to remove default or change the name and add description","2024-11-03T03:36:50Z","https://github.com/enzonotario/vitepress-openapi/issues/109",0.8287165,["Reactive",3110],{},["Set"],["ShallowReactive",3113],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fTi8mSu5spQkcm9chd48E4nQlE5Z7AruYFXQoPLgYDzA":-1},"/enzonotario/vitepress-openapi/247"]