\n\n### Additional context\n\n_No response_",[3150,3153,3156],{"name":3151,"color":3152},"enhancement","a2eeef",{"name":3154,"color":3155},"v3","49DCB8",{"name":3157,"color":3158},"triage","ffffff",4788,"ui","[Feature Request] Add Descriptions component","2025-08-19T03:39:55Z","https://github.com/nuxt/ui/issues/4788",0.7096767,{"description":3166,"labels":3167,"number":3172,"owner":3141,"repository":3160,"state":3142,"title":3173,"updated_at":3174,"url":3175,"score":3176},"### Description\n\nThinking through the complexities of form management, and the current implementation in Nuxt UI, I'm wondering, would it make sense to defer the \"heavy lifting\" to external form libraries?\n\nForms can get pretty complicated as the data model becomes more complex. That is where established form libraries shine.\n\nThese are some libraries that I've used with NuxtUi myself, (granted with various levels of boilerplate that is required).\n\n**Formwerk**\nhttps://formwerk.dev/\n- I'm involved in this project\n- Its intended, primarily, to be incorporated in UI libraries.\n- I've worked with its creator @logaretm and I'm sure he'd be willing to support any integration challenges. \n- Very well written code and highly tested.\n\n**Reagle**\nhttps://github.com/victorgarciaesgi/regle\n- Fairly new, but it takes an interesting headless approach.\n- Could potentially be the easiest to integrate\n- Because its fairly new, It may not be as well documented or battle tested with complex forms\n\nNon-vue specific libraries\n**Tanstack Forms**\nhttps://tanstack.com/form/latest\n- We already use tanstack table, so this could make sense\n- Its still relatively new -- it may not be as polished for the vue ecosystem.\n \n...possibly more?\n\n@romhml since you made significant contributions to the form implementation in Nuxt UI, I would love to hear your thoughts. Do you envision the current implementation to be expanded?",[3168,3171],{"name":3169,"color":3170},"question","d876e3",{"name":3154,"color":3155},4724,"Defer form functionality to third party","2025-08-14T15:14:08Z","https://github.com/nuxt/ui/issues/4724",0.7139266,{"description":3178,"labels":3179,"number":3183,"owner":3141,"repository":3160,"state":3142,"title":3184,"updated_at":3185,"url":3186,"score":3187},"### Description\n\nI propose the addition of a UTheme component which would allow scoped theming of components to reduce repeated styling that's error prone when refactoring.\n\n## Example\nThe Dashboard template has a bunch of forms that have horizontal form fields (label left, input right).\n\nBefore:\n```html\n\u003CUForm ...>\n \u003CUFormField ... class=\"flex max-sm:flex-col justify-between items-center gap-4\">\n ...\n \u003CUFormField>\n \u003CUFormField ... class=\"flex max-sm:flex-col justify-between items-center gap-4\">\n ...\n \u003CUFormField>\n\u003CUForm/>\n```\n\nAfter:\n```html\n\u003C!-- `ui` prop is the same as `app.config.ts` theming config\n\u003CUTheme :ui=\"{\n formField: {\n\t slots: {\n\t root: \"flex max-sm:flex-col justify-between items-center gap-4\",\n\t},\n },\n}\">\n \u003CUForm ...>\n \u003CUFormField ...>\n ...\n \u003CUFormField>\n \u003CUFormField ...>\n ...\n \u003CUFormField>\n \u003CUForm/>\n\u003C/UTheme>\n```\n\n## Benefits\n- Easily componentized. I could create a `AppForm` component which contains the `UTheme` usage with a slot, so now its 1 line to get the exact theming that I want. This makes consistency across the app really easy.\n- Nestable - If implemented with provide/inject, you could have an infinite number of UTheme's nested and it would take the latest one\n\n## Implementation\nI'd tentatively be willing to implement this. My approach would be:\n- Create `UTheme`, it should have a `ui` and `uiPro` prop, each of which take the same type as the `app.config.ts`\n- `provide()` those props\n- `inject()` those props into each component and merge with passed in `ui` field.\n- Theme priority order should be:\n 1. `ui` prop passed to component\n 2. `ui` prop coming from UTheme component\n 3. `ui` config coming from `app.config.ts`\n\n### Additional context\n\n_No response_",[3180,3181,3182],{"name":3151,"color":3152},{"name":3154,"color":3155},{"name":3157,"color":3158},4250,"UTheme component","2025-05-28T22:24:36Z","https://github.com/nuxt/ui/issues/4250",0.7151608,{"description":3189,"labels":3190,"number":3205,"owner":3141,"repository":3141,"state":3142,"title":3206,"updated_at":3207,"url":3208,"score":3209},"### Describe the feature\r\n\r\nEdit : Form actions have been released as a Nuxt module 🎉 Please try it and leave feedback.\r\n\r\n- Docs : https://form-actions-nuxt.pages.dev/\r\n- Module : https://nuxt.com/modules/form-actions\r\n- GitHub : https://github.com/Hebilicious/form-actions-nuxt\r\n\r\n--- \r\n\r\nProgressively enhanced patterns relies on using native forms to make it easier to have apps that works without JavaScript. This can work well with Nuxt Server components too, as it could allow client-server communication with 0client side javascript. While this is not desirable in all scenarios, and having this as the default to do everything is very opinionated, it would be nice to support these patterns at the framework level : \r\n\r\nMultiple frameworks already support this pattern (Remix, SvelteKit, SolidStart ...), and Next is adding it :\r\n\r\n\r\nFor Nuxt, it's (almost) possible already to implement this patterns by doing something like this (in /server/api/pespa.ts) : \r\n\r\n```ts\r\nimport { EventHandler, H3Event } from \"h3\"\r\n\r\ntype Actions = {\r\n [key: string]: EventHandler\r\n}\r\n\r\nconst defineFormActions = (actions: Actions) => async (event: H3Event) => {\r\n const action = Object.keys(getQuery(event))[0] ?? \"default\"\r\n const method = getMethod(event)\r\n if (method === \"POST\") return defineEventHandler(actions[action])(event)\r\n}\r\n\r\nexport default defineFormActions({\r\n default: async (event) => {\r\n const form = await readMultipartFormData(event)\r\n const body = await readBody(event)\r\n const contentType = getHeader(event, \"content-type\")\r\n console.log({ form, body, contentType })\r\n return sendRedirect(event, \"/pespa\")\r\n },\r\n logout: async (event) => {\r\n const form = await readMultipartFormData(event)\r\n const body = await readBody(event)\r\n const contentType = getHeader(event, \"content-type\")\r\n console.log({ form, body, contentType })\r\n return sendRedirect(event, \"/pespa\")\r\n }\r\n})\r\n```\r\n\r\nThen creating a page at /pespa ...\r\n```vue\r\n\u003Ctemplate>\r\n \u003Cform method=\"POST\" action=\"api/pespa\">\r\n \u003Clabel>\r\n Email\r\n \u003Cinput name=\"email\" type=\"email\" value=\"john@doe.com\" />\r\n \u003C/label>\r\n \u003Clabel>\r\n Password\r\n \u003Cinput name=\"password\" type=\"password\" value=\"password\" />\r\n \u003C/label>\r\n \u003Cbutton>Log in\u003C/button>\r\n \u003C/form>\r\n \u003Cform method=\"POST\" action=\"api/pespa?logout\">\r\n \u003Cbutton>Log Out\u003C/button>\r\n \u003C/form>\r\n\u003C/template>\r\n```\r\n\r\nHowever here we have to use \"/api\" for the action attribute, and the DX isn't the best for multiple reasons.\r\n\r\nIt would be nice to have a `/actions` directory (in `/server` for nuxt) so that we can define form actions more easily. \r\n(This probably needs a discussion/RFC somewhere so that the Nuxt/Nitro/H3 side can be updated together, let me know if I should repost this somewhere else)\r\n\r\nFor the nitro syntax, the `defineFormAction` I proposed above could be integrated in nitro, as a replacement for defineEventHandler. \r\n\r\nI'm not sure if manually redirecting in the action handler is the best way to do things, perhaps what would need to happen for Nuxt specifically is to generate POST only handlers for these form actions, while these GET methods to the same URL are handled by the corresponding route or nuxt page.\r\n\r\nIf I'm not mistaken, for Nuxt we also need a way to easily pass data back and forth, perhaps the existing ways can be used, but a new composable feels appropriate. \r\n\r\nThere's also a need for something similar to sveltekit [use:enhance / applyAction](https://kit.svelte.dev/docs/form-actions#progressive-enhancement) to make it easier to progressively enhance forms (altough, e.preventDefault() could be enough, the DX is a little barebones)\r\n\r\nHaving something like `getNativeRequest` from H3 would be really useful too: \r\n\r\n```ts\r\neventHandler(event => {\r\nconst request = getNativeRequest(event)\r\nconst data = request.formData()\r\n//do stuff\r\n})\r\n```\r\n*This might need some change in @vue/core, see [React here.](https://github.com/facebook/react/pull/26749)*\r\n\r\n### Proposed API :\r\n\r\nI'm suggesting an API here to illustrate what we could do. \r\n\r\n`pages/signIn.vue`\r\n```vue\r\n\u003Cscript setup> \r\nconst { enhance } = useEnhance(({form, data, action, cancel, submitter }) => {\r\n // Using SvelteKit API to illustrate, but the Nuxt one could/should be different ...\r\n // `form` is the `\u003Cform>` element;`data` is its `FormData` object\r\n // `action` is the URL to which the form is posted;v`cancel()` will prevent the submission\r\n // `submitter` is the `HTMLElement` that caused the form to be submitted\r\n return async ({ result, update }) => {\r\n // `result` is returned by the matching defineFormAction ....\r\n // `update` is a function which triggers the logic that would be triggered if this callback wasn't set\r\n };\r\n})\r\n\r\n// Alternatively something like this, which I personally prefer...\r\nconst { result, loading, error, enhance } = useAction(\"signIn\", (actionSettings) => {\r\n// actions settings could contain form, data, action, cancel ... like in useEnhance\r\n}) \r\n//Can use result/loading/error etc in the template for conditional rendering\r\n\u003C/script>\r\n\u003Ctemplate>\r\n \u003Cform method=\"post\" action=\"signIn\" v-enhance=\"enhance\">\r\n \u003Clabel>\r\n Email\r\n \u003Cinput name=\"email\" type=\"email\" value=\"john@doe.com\" />\r\n \u003C/label>\r\n \u003Clabel>\r\n Password\r\n \u003Cinput name=\"password\" type=\"password\" value=\"password\" />\r\n \u003C/label>\r\n \u003Cbutton>Log in\u003C/button>\r\n \u003C/form>\r\n\u003C/template>\r\n```\r\n\r\n`server/signIn.vue`\r\n```ts\r\nexport defineFormAction((event) => {\r\n const request = getNativeRequest(event)\r\n const data = request.formData()\r\n \r\n// signin the User\r\n// Not that we should have a way to return something that works \r\n// well with progressive enhancement to the client,\r\n//Like a JSON payload that can contain data and \"metadata\" (errors, redirects )\r\n// so they can be applied smoothly in CSR. \r\n// A `respondWithFormAction` helper could be added too.\r\nconst result = `This was sent ${JSON.stringify(data)}`\r\nreturn actionResponse(event, { result } )\r\n})\r\n```\r\n\r\nTo recap here : \r\n\r\n- New vue directive for nuxt, `v-enhance` to use on forms to enhance them\r\n- New event handler for Nitro or H3, `defineFormAction`. Could accept a function or an object of functions\r\n- New server directory for Nitro `/server/actions` to define server actions.\r\n- New helpers for H3 `getNativeRequest()` and `actionResponse()` to simplify the action workflow\r\n- New feature for Nuxt, `useAction` or `useEnhance`, to work with actionResponse and v-enhance. \r\n\r\nOverall I feel like this API is respectful of the standard web semantics, and feels vue-ish. Feel free to suggest any improvements for it.\r\n\r\n### Reference from other frameworks : \r\n- [Svelte Form actions](https://kit.svelte.dev/docs/form-actions), [Discussion for semantic form actions](https://github.com/sveltejs/kit/discussions/5875)\r\n- [Solid Start actions](https://start.solidjs.com/core-concepts/actions)\r\n- [Remix Actions](https://remix.run/docs/en/main/route/action)\r\n- [Kent PESPA article](https://www.epicweb.dev/the-webs-next-transition)\r\n- [Next.js Server Actions](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions)\r\n\r\n### Additional information\r\n\r\n- [X] Would you be willing to help implement this feature?\r\n- [ ] Could this feature be implemented as a module?\r\n\r\n### Final checks\r\n\r\n- [X] Read the [contribution guide](https://nuxt.com/docs/community/contribution).\r\n- [X] Check existing [discussions](https://github.com/nuxt/nuxt/discussions) and [issues](https://github.com/nuxt/nuxt/issues).",[3191,3193,3196,3199,3202],{"name":3151,"color":3192},"8DEF37",{"name":3194,"color":3195},"discussion","538de2",{"name":3197,"color":3198},"dx","C39D69",{"name":3200,"color":3201},"nitro","bfd4f2",{"name":3203,"color":3204},"🍰 p2-nice-to-have","0E8A16",20649,"Form actions for progressive enhancement","2024-06-30T11:08:54Z","https://github.com/nuxt/nuxt/issues/20649",0.720544,{"description":3211,"labels":3212,"number":3214,"owner":3141,"repository":3141,"state":3142,"title":3215,"updated_at":3216,"url":3217,"score":3218},"### Describe the feature\n\n### Context\n\nCurrently, Nuxt supports layouts via the `layouts/` directory and supports nested UI sections using **nested routes** (e.g., `pages/profile.vue` wrapping `pages/profile/favorite.vue`). While this works, once the project grows with many folders and files, the pattern of mixing `parent.vue` (used as a wrapper) alongside actual child routes can get confusing and lose context.\n\nFor example:\n\n```\npages/\n ├─ profile.vue // Parent layout wrapper\n └─ profile/\n ├─ index.vue // Child route\n └─ favorite.vue // Child route\n```\n\nHere, `profile.vue` is conceptually acting as a **nested layout**, but it is treated as a page, which can make code organization less clear.\n\n### Problem\n\n* `parent.vue` files inside `pages/` double as both “layout” and “page,” which can blur their purpose.\n* As the folder structure deepens, it becomes harder to distinguish what is a layout wrapper and what is an actual page.\n* The developer has to “remember” which `.vue` file is serving as a pseudo-layout.\n\n### Proposal / Suggestion\n\nIntroduce a **dedicated convention** for nested layouts within route groups.\n\nFor example:\n\n```\npages/\n └─ profile/\n ├─ @layout.vue // Explicitly marks this as the wrapper layout\n ├─ index.vue // Child route\n └─ favorite.vue // Child route\n```\n\nUsage:\n\n```vue\n\u003C!-- pages/profile/@layout.vue -->\n\u003Ctemplate>\n \u003Cdiv class=\"flex\">\n \u003CSidebar />\n \u003CNuxtPage /> \u003C!-- renders children like index.vue, favorite.vue -->\n \u003C/div>\n\u003C/template>\n```\n\nThis improves clarity by:\n\n* Explicitly distinguishing **nested layout files** from **page files**.\n* Avoiding the overloaded role of `parent.vue`.\n* Making folder structures self-explanatory.\n\n### Benefits\n\n* More intuitive project structure for large apps.\n* Easier onboarding for new developers (clear separation of layouts vs. pages).\n* Cleaner, scalable convention that aligns with the mental model of “global layouts” vs. “section layouts.”\n\n### Additional information\n\n- [x] Would you be willing to help implement this feature?\n- [ ] Could this feature be implemented as a module?\n\n### Final checks\n\n- [x] Read the [contribution guide](https://nuxt.com/docs/community/contribution).\n- [x] Check existing [discussions](https://github.com/nuxt/nuxt/discussions) and [issues](https://github.com/nuxt/nuxt/issues).",[3213],{"name":3138,"color":3139},33073,"[Enhancement] Better Syntax/Convention for Nested Layouts in Nuxt","2025-08-27T05:51:23Z","https://github.com/nuxt/nuxt/issues/33073",0.7285874,{"description":3220,"labels":3221,"number":3224,"owner":3141,"repository":3160,"state":3142,"title":3225,"updated_at":3226,"url":3227,"score":3228},"### Description\n\nIn the Nuxt UI documentation, the theme configuration JSON for components is extremely helpful for understanding default styles and customizing them. However, these blocks currently do not support expanding/collapsing of nested sections like slots, variants, or size, which makes navigation and readability difficult—especially for large configuration trees.\n\n**Feature Request:**\nAdd interactive expand/collapse support to nested JSON blocks in the theme section of the Nuxt UI docs. This can be similar to how most code editors and browser devtools handle JSON structures, allowing users to collapse/expand objects or arrays.\n\n**Use Cases:**\n- Improved UX for developers customizing UI themes\n- Faster navigation when working with deeply nested or verbose configurations\n- Easier understanding of available slots and variants without scrolling through long blocks\n\n**Alternatives Considered:**\n- Copying the JSON into a code editor to navigate — which breaks the in-context experience\n- Searching for keys manually, which is slow and error-prone\n\n**Prototype / Reference:**\nAlthough no direct prototype is available, the expected behavior is similar to how Vue DevTools or VSCode handles collapsible JSON structures.\n\n\u003Cimg width=\"844\" height=\"619\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/14f7ccb8-3e7e-41f5-8b6e-6ffc5f2ba150\" />\n\n### Additional context\n\n_No response_",[3222,3223],{"name":3151,"color":3152},{"name":3157,"color":3158},4606,"✨ Expand/Collapse Support for Component Theme JSON in Nuxt UI Docs","2025-07-26T11:50:47Z","https://github.com/nuxt/ui/issues/4606",0.7296536,{"description":3230,"labels":3231,"number":3242,"owner":3141,"repository":3160,"state":3243,"title":3244,"updated_at":3245,"url":3246,"score":3247},"### Description\n\n### 🚀 Feature Request\nI’d like to suggest adding a built-in `\u003CDynamicRenderer>` component to Nuxt UI that renders dynamic, nested components based on a configuration object.\n\n### 📋 Motivation\nThis component would be ideal for:\n\n- Form builders\n\n- CMS-driven UIs\n\n- Low-code tools\n\n- Declarative UI rendering\n\nIt simplifies the process of rendering deeply nested structures without hardcoding components in the template.\n\n### 💡 Proposal\nThe DynamicRenderer would accept a config prop that defines:\n\n- The component to render\n\n- Props to bind\n\n- Slot content (including nested component trees)\n\nIt would recursively render components and their slots. Here's an example implementation:\n\n\n#### `DynamicRenderer.vue`\n```vue\n\u003Cscript setup lang=\"ts\">\ndefineProps\u003C{ config: any }>()\n\u003C/script>\n\n\u003Ctemplate>\n \u003Ccomponent :is=\"config.component\" v-bind=\"config\">\n \u003Ctemplate\n v-for=\"(slotContent, slotName) in config.slots\"\n #[slotName]\n >\n \u003Ctemplate v-if=\"typeof slotContent === 'string'\">\n {{ slotContent }}\n \u003C/template>\n\n \u003Ctemplate v-else-if=\"Array.isArray(slotContent)\">\n \u003CDynamicRenderer\n v-for=\"(nested, index) in slotContent\"\n :key=\"index\"\n :config=\"nested\"\n />\n \u003C/template>\n\n \u003Ctemplate v-else>\n \u003CDynamicRenderer :config=\"slotContent\" :key=\"slotContent.name || slotName\" />\n \u003C/template>\n \u003C/template>\n \u003C/component>\n\u003C/template>\n```\n\n\n\n#### `index.vue`\n```vue\n\u003Cscript setup lang=\"ts\">\nimport { UButton, UCard, UContainer, UForm, UFormField, UInput } from '#components'\n\nconst config = {\n component: UContainer,\n class: 'h-screen flex justify-center items-center',\n slots: {\n default: [\n {\n component: UCard,\n slots: {\n default: [{\n component: UForm,\n class: 'space-y-4',\n slots: {\n default: [\n {\n component: UFormField,\n label: 'Username',\n name: 'username',\n required: true,\n slots: {\n default: [\n {\n component: UInput,\n placeholder: 'Enter Username',\n value: 'hh'\n }\n ]\n }\n },\n {\n component: UFormField,\n label: 'Password',\n name: 'password',\n required: true,\n slots: {\n default: [\n {\n component: UInput,\n type: 'password',\n placeholder: 'Enter Password',\n value: 'hh'\n }\n ]\n }\n },\n {\n component: UButton,\n label: 'Login',\n icon: 'i-lucide-user',\n variant: 'soft',\n type: 'submit',\n block: true\n }\n ]\n }\n }]\n }\n }\n ]\n }\n}\n\u003C/script>\n\n\u003Ctemplate>\n \u003CDynamicRenderer :config=\"config\" />\n\u003C/template>\n```\n\n### Result \n\n\nIt would also be great if using this approach could eliminate the need to manually import components like:\n\n```ts\nimport { UButton, UCard, UContainer, UForm, UFormField, UInput } from '#components'\n```\n\nand instead rely on automatic resolution by the renderer itself.\n\nThanks for your work on Nuxt UI – it’s a fantastic toolkit!\n\n### Additional context\n\n_No response_",[3232,3235,3236,3237,3240],{"name":3233,"color":3234},"feature","A27AF6",{"name":3154,"color":3155},{"name":3157,"color":3158},{"name":3238,"color":3239},"closed-by-bot","ededed",{"name":3241,"color":3239},"stale",4138,"closed","✨ Feature Request: Add `\u003CDynamicRenderer>` component for config-driven UI rendering","2025-09-03T02:01:06Z","https://github.com/nuxt/ui/issues/4138",0.70089257,{"description":3249,"labels":3250,"number":3254,"owner":3141,"repository":3160,"state":3243,"title":3255,"updated_at":3256,"url":3257,"score":3258},"### Description\n\nI’d like to import Zod schemas for all built-in Nuxt UI components from the `@nuxt/ui` package so that my frontmatter validation in `content.config.ts` is accurate, DRY, and immediately usable.\n\n**Use case**\n\n- **Accurate frontmatter validation** for Nuxt Studio\n Pull in ready-to-use schemas for:\n\n - **Enums** like button `variant` or `color`\n - **Common elements** such as `Image`\n - **Complex components** like `PageSection`\n\n**Alternatives considered**\n\n* Manually recreating every enum, element, and component shape in custom Zod files (error-prone and high maintenance).\n *See a manual example here:*\n [https://github.com/nuxt-ui-pro/saas/blob/main/content.config.ts](https://github.com/nuxt-ui-pro/saas/blob/main/content.config.ts)\n\n**Proposed solution**\n\n- Publish each component’s Zod schema under `@nuxt/ui/schemas/{ComponentName}.ts` (e.g. `@nuxt/ui/schemas/PageSection.ts`)\n- Provide a barrel file for easy imports:\n\n ```ts\n import {\n colorEnum \n createImageSchema,\n createLinkSchema,\n createPageSectionSchema,\n } from '@nuxt/ui'\n ```\n\n### Additional context\n\n_No response_",[3251,3252,3253],{"name":3151,"color":3152},{"name":3154,"color":3155},{"name":3157,"color":3158},4161,"Export Zod schemas for Nuxt UI component props for use in content.config.ts","2025-05-28T13:02:08Z","https://github.com/nuxt/ui/issues/4161",0.71383154,{"description":3260,"labels":3261,"number":3266,"owner":3141,"repository":3141,"state":3243,"title":3267,"updated_at":3268,"url":3269,"score":3270},"### What problem does this feature solve?\n\nOffer the ability to scaffold a basic CRUD user interface\n\n### What does the proposed changes look like?\n\nGiven a command similar to how Rails solves scaffolding:\n\n`nuxt scaffold widget name:string title:string updated_at:datetime`\n\nNuxt creates a basic scaffolding for a Vuex store, pages, and a form component.\n\n\u003C!--cmty-->\u003C!--cmty_prevent_hook-->\n\u003Cdiv align=\"right\">\u003Csub>\u003Cem>This feature request is available on \u003Ca href=\"https://cmty.app/nuxt\">Nuxt\u003C/a> community (\u003Ca href=\"https://cmty.app/nuxt/nuxt.js/issues/c7453\">#c7453\u003C/a>)\u003C/em>\u003C/sub>\u003C/div>",[3262,3263],{"name":3151,"color":3192},{"name":3264,"color":3265},"2.x","d4c5f9",3602,"Scaffold a basic CRUD structure","2023-01-22T15:50:41Z","https://github.com/nuxt/nuxt/issues/3602",0.7154188,["Reactive",3272],{},["Set"],["ShallowReactive",3275],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$f2EApXHWHIcSHlJtHnrgA_JWC1iAKMmRgOQmfBvs32fI":-1},"/nuxt/ui/4653"]