\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.7974266,{"description":3059,"labels":3060,"number":3061,"owner":3020,"repository":3021,"state":3034,"title":3062,"updated_at":3063,"url":3064,"score":3065},"### Current behavior\n\nIn OpenAPI you can create a nullable object with:\n```yaml\ntype: [object, 'null']\nproperties:\n example:\n type: string\n```\n\nCurrently, vitepress-openapi will not display the properties correctly.\n\n### Desired behavior\n\nIf the object is nullable, it should still list all properties of nullable object and not just `object | null`\n\n### Reproduction\n\n_No response_\n\n### Steps to reproduce\n\n```json\n{\n \"openapi\": \"3.1.0\",\n \"info\": {\n \"title\": \"Nullable objects\"\n },\n \"servers\": [\n {\n \"url\": \"https://whatever.com\",\n \"description\": \"Mock Server\"\n }\n ],\n \"paths\": {\n \"/nullable\": {\n \"get\": {\n \"tags\": [\n \"Nullable\"\n ],\n \"summary\": \"Get nullable object\",\n \"description\": \"Yayy\",\n \"operationId\": \"getNullableObject\",\n \"responses\": {\n \"200\": {\n \"description\": \"OK\",\n \"content\": {\n \"application/json\": {\n \"schema\": {\n \"type\": \"object\",\n \"properties\": {\n \"a\": {\n \"type\": [\n \"object\",\n \"null\"\n ],\n \"properties\": {\n \"a\": {\n \"type\": \"number\"\n }\n }\n }\n }\n }\n }\n }\n }\n }\n }\n }\n },\n \"tags\": [],\n \"externalDocs\": {}\n}\n```\n\n\n\n### Logs and Error Messages\n\n_No response_\n\n### Other Information\n\n_No response_",[],206,"\"nullable\" objects","2025-04-24T01:25:01Z","https://github.com/enzonotario/vitepress-openapi/issues/206",0.8036205,{"description":3067,"labels":3068,"number":3072,"owner":3020,"repository":3021,"state":3034,"title":3073,"updated_at":3074,"url":3075,"score":3076},"### What would you like?\n\nVitepress-openapi is beautiful. I have a doc site already, and I would like to add the vitepress-openapi docs as a menu item on my top navigation menu. \r\n\r\n\r\n\n\n### Why is this needed?\n\nThere is often a lot of material besides the openapi specification that one needs for documentation. I'd like to be able to include the openapi site within another site to keep everything together.\n\n### How could it be implemented?\n\nI'm not knowledgeable enough to know. Right now I am embedding `openapi-explorer` in a simple `layout: page` page associated with the menu item:\r\n\r\n```vue\r\n---\r\nlayout: page\r\nsidebar: false\r\n---\r\n\u003Cscript setup>\r\n import 'openapi-explorer/dist/es/openapi-explorer.js';\r\n import { useData } from 'vitepress'\r\n const { isDark, theme, page, frontmatter } = useData()\r\n\u003C/script>\r\n\r\n\u003CClientonly>\r\n \u003Copenapi-explorer\r\n v-if = isDark\r\n spec-url = \"/adm-spec.yaml\"\r\n hide-console = true\r\n hide-authentication = true\r\n hide-server-selection = true\r\n hide-components = false\r\n nav-bg-color = #1b1b1f\r\n secondary-color = #F8F8F5\r\n nav-hover-text-color = #85bd4f\r\n bg-color = #1b1b1f\r\n text-color = \"#F8F8F5\"\r\n >\r\n \u003C/openapi-explorer>\r\n\r\n\r\n \u003Copenapi-explorer\r\n v-else\r\n spec-url = \"/adm-spec.yaml\"\r\n hide-console = true\r\n hide-authentication = true\r\n hide-server-selection = true\r\n hide-components = false\r\n nav-bg-color = #ffffff\r\n secondary-color = #000000\r\n nav-hover-text-color = #F8F8F5\r\n >\r\n \u003C/openapi-explorer>\r\n\r\n\u003C/ClientOnly>\r\n```\r\n\r\nThis seems very awkward, and it's difficult to get the styles to match Vitepress's theme. Might there be a way to extend the default theme with a layout called `openapi` and somehow link my spec file in the front matter?\n\n### Other information\n\nI appreciate this work very much. Thanks for considering the suggestion.",[3069],{"name":3070,"color":3071},"question","d876e3",71,"Is it possible to add vitepress-openapi to an existing Vitepress site as a menu item","2024-10-19T02:30:08Z","https://github.com/enzonotario/vitepress-openapi/issues/71",0.80403286,{"description":3078,"labels":3079,"number":104,"owner":3020,"repository":3084,"state":3034,"title":3085,"updated_at":3086,"url":3087,"score":3088},"Que en cada pagina de una votacion o senador estemos usando esa info para generar la metadata y de esa manera mejorar ranking en google",[3080,3081],{"name":3043,"color":3044},{"name":3082,"color":3083},"good first issue","7057ff","senadores","Metadata correcta en cada pagina","2025-02-23T14:56:14Z","https://github.com/enzonotario/senadores/issues/3",0.810207,{"description":3090,"labels":3091,"number":3095,"owner":3020,"repository":3096,"state":3034,"title":3097,"updated_at":3098,"url":3099,"score":3100},"\r\n\r\nDurante unos minutos hoy me encontre con esta respuesta para el blue\r\n",[3092],{"name":3093,"color":3094},"bug","d73a4a",14,"esjs-dolar-api","Error en la cotizacion del blue","2024-02-09T14:54:40Z","https://github.com/enzonotario/esjs-dolar-api/issues/14",0.81966096,{"description":3102,"labels":3103,"number":3105,"owner":3020,"repository":3021,"state":3034,"title":3106,"updated_at":3107,"url":3108,"score":3109},"### 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_",[3104],{"name":3043,"color":3044},127,"Overwrite \"Try It Out\" url","2024-12-21T01:51:19Z","https://github.com/enzonotario/vitepress-openapi/issues/127",0.8200705,{"description":3111,"labels":3112,"number":3114,"owner":3020,"repository":3021,"state":3034,"title":3115,"updated_at":3116,"url":3117,"score":3118},"### 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.",[3113],{"name":3043,"color":3044},92,"Modify Sample Code Based on Variables","2024-11-15T02:40:07Z","https://github.com/enzonotario/vitepress-openapi/issues/92",0.82032275,["Reactive",3120],{},["Set"],["ShallowReactive",3123],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$f1VN8mm9Evj1LFXb0ZN9oLY9TMg7mBetdEtXYXeNcM2A":-1},"/enzonotario/vitepress-openapi/141"]