\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_",[2852,2855],{"name":2853,"color":2854},"enhancement","a2eeef",{"name":2856,"color":2857},"triage","ffffff",4138,"nuxt","ui","open","✨ Feature Request: Add `\u003CDynamicRenderer>` component for config-driven UI rendering","2025-05-12T16:36:30Z","https://github.com/nuxt/ui/issues/4138",0.6901938,{"description":2867,"labels":2868,"number":2875,"owner":2859,"repository":2860,"state":2861,"title":2876,"updated_at":2877,"url":2878,"score":2879},"### Description\n\nIs there a way to add custom props to a component for styling—similar to how variant works for buttons? I’d like to add variant support to FormField, but currently, it only supports size.\n\nMy main goal is to allow styling of components provided by my Nuxt module. Ideally, I want to define variants and extra props via app.config.ts. An alternative approach I'm thinking of is to offer per-component config options, similar to Nuxt UI, but managed separately from its config.",[2869,2872],{"name":2870,"color":2871},"question","d876e3",{"name":2873,"color":2874},"v3","49DCB8",4148,"Additional props like variants for styling","2025-05-14T12:47:31Z","https://github.com/nuxt/ui/issues/4148",0.72573525,{"description":2881,"labels":2882,"number":2888,"owner":2859,"repository":2859,"state":2861,"title":2889,"updated_at":2890,"url":2891,"score":2892},"### Describe the feature\n\nSometimes you need to have multiple components in the `app.vue` file, or as close to the root element as possible. For example, if you have multiple modals that must be present not only on every page, but also on every layout (dialogs, cookie notice, etc) or any other interface resource and you must add each one manually somewhere in the `app.vue` file.\r\n\r\nI think it would be nice to have a directory for \"universal\" components that Nuxt detects and automatically injects into the root element. This would perfectly follow the philosophy of the framework to improve the DX as much as possible.\r\n\r\nAn example of how it would be now and how it could be:\r\n\r\n```vue\r\n// ~/app.vue\r\n\u003Ctemplate>\r\n \u003Cdiv>\r\n \u003CNuxtLayout>\r\n \u003CNuxtPage />\r\n \u003C/NuxtLayout>\r\n \u003C!-- universal components -->\r\n \u003CMenuDialog />\r\n \u003CLanguageDialog />\r\n \u003CColorModeDialog />\r\n \u003CBackdrop />\r\n \u003C!-- etc -->\r\n \u003C/div>\r\n\u003C/template>\r\n```\r\nOr you could just move those components to a directory called `~/components/universal` (for example) and Nuxt would take care of injecting them automatically.\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).",[2883,2885],{"name":2853,"color":2884},"8DEF37",{"name":2886,"color":2887},"discussion","538de2",19492,"Components automatically injected into the root element","2024-06-30T11:09:20Z","https://github.com/nuxt/nuxt/issues/19492",0.7371852,{"description":2894,"labels":2895,"number":2902,"owner":2859,"repository":2859,"state":2861,"title":2903,"updated_at":2904,"url":2905,"score":2906},"### Environment\r\n\r\n- Operating System: Darwin\r\n- Node Version: v20.10.0\r\n- Nuxt Version: 3.12.3\r\n- CLI Version: 3.12.3\r\n- Nitro Version: 2.9.6\r\n- Package Manager: pnpm@6.11.0\r\n- Builder: -\r\n\r\n### Reproduction\r\n\r\nhttps://stackblitz.com/edit/github-qwsfdu\r\n\r\n### Describe the bug\r\n\r\n- Nest a 'universal' component within a server component.\r\n- Have `@unocss/nuxt` module. \r\n- Run `npm run build` then `npm run preview`\r\n- The nested component has no styling\r\n\r\n### Additional context\r\n\r\nAlmost certainly related to https://github.com/nuxt/nuxt/issues/27584\r\n\r\n### Logs\r\n\r\n_No response_",[2896,2899],{"name":2897,"color":2898},"pending triage","E99695",{"name":2900,"color":2901},"server components","839413",28043,"Styles removed from components nested in 'Server Components' during build when unocss present","2024-07-05T09:48:52Z","https://github.com/nuxt/nuxt/issues/28043",0.73820555,{"description":2908,"labels":2909,"number":2913,"owner":2859,"repository":2860,"state":2861,"title":2914,"updated_at":2915,"url":2916,"score":2917},"### Description\n\nI've used [Quasar's tree-component with checkboxes](https://quasar.dev/vue-components/tree#tick-strategy) as a form element in several use-cases. It's an extremely useful element for hierarchical content when it makes sense that the user is able to see all options simultaneously (i.e. not hidden in a dropdown or something similar).\n\nI can see that this component variant is mentioned on [Reka-ui's docs page](https://reka-ui.com/docs/components/tree#with-checkbox).\n\nAre there any plans to add this?\n\n### Additional context\n\n_No response_",[2910,2911,2912],{"name":2853,"color":2854},{"name":2873,"color":2874},{"name":2856,"color":2857},4243,"UTree with checkboxes","2025-05-28T13:19:10Z","https://github.com/nuxt/ui/issues/4243",0.7417666,{"description":2919,"labels":2920,"number":2926,"owner":2859,"repository":2860,"state":2927,"title":2928,"updated_at":2929,"url":2930,"score":2931},"### Environment\n\n- Operating System: Darwin\n- Node Version: v20.18.3\n- Nuxt Version: 3.16.2\n- CLI Version: 3.24.1\n- Nitro Version: 2.11.9\n- Package Manager: bun@1.1.28\n- Builder: -\n- User Config: devtools, modules, css, future, compatibilityDate\n- Runtime Modules: @nuxt/ui@3.0.2, @nuxt/eslint@1.3.0\n- Build Modules: -\n\n### Is this bug related to Nuxt or Vue?\n\nNuxt\n\n### Version\n\nv3.0.2\n\n### Reproduction\n\nhttps://stackblitz.com/edit/github-s2opq2ko?file=app/pages/index.vue\n\n### Description\n\nGiven this component nesting:\n\n- `UForm`\n - `UModal`\n - `UForm`\n\nThis is rendered as the following html:\n\n- `UForm` -> `form` - ✅\n - `UModal` -> `div` - ✅ (teleported to root)\n - `UForm` -> `div` - ❌ I am expecting `form`.\n\nI couldn't find a mention in the documentation that this is expected behaviour.\n\nTo reproduce:\n1. Run reproduction\n2. Click \"Open modal\" button\n3. Inspect the nested form element. It's a `div`:\n\n\nI am happy to have a crack at a PR, if you're willing to point me in the right direction 😌\n\n\n### Additional context\n\nFor context, this is our use case:\n* User fills out an onboarding form\n* One field in the onboarding form is business details\n* User has option to populate business details via business number (eg. [DUNS](https://www.dnb.com/en-us/smb/duns.html))\n* Business number field open in modal\n* User can enter business number in form in modal\n* User submits form, it populates state in parent form\n\n### Logs\n\n```shell-script\n\n```",[2921,2924,2925],{"name":2922,"color":2923},"bug","d73a4a",{"name":2873,"color":2874},{"name":2856,"color":2857},3913,"closed","[Form] Nested `UForm` in `UModal` is not rendered as `form`","2025-04-16T08:34:48Z","https://github.com/nuxt/ui/issues/3913",0.715745,{"description":2933,"labels":2934,"number":2938,"owner":2859,"repository":2860,"state":2927,"title":2939,"updated_at":2940,"url":2941,"score":2942},"### Description\n\nThe [popover](https://ui.nuxt.com/components/popover) uses the content of the default slot to create a trigger, but there is no way to provide a custom anchor. A `\u003Ctemplate #anchor>` slot for this purpose would be great.\n\n```html\n\u003CUFormField label=\"name\" name=\"name\">\n \u003CUPopover :open=\"isAutoCompleteOpen\">\n \u003Ctemplate #anchor>\n \u003CUInput v-model=\"state.name\" />\n \u003C/template>\n \u003Ctemplate #content>\n \u003CPlaceholder class=\"size-48 m-4 inline-flex\" />\n \u003C/template>\n \u003C/UPopover>\n\u003C/UFormField>\n```\n\nMy use case is building an autocomplete for a text input. The `InputMenu` is not suitable because the dropdown is too intrusive.\n\n### Additional context\n\n_No response_",[2935,2936,2937],{"name":2853,"color":2854},{"name":2873,"color":2874},{"name":2856,"color":2857},4013,"Add ability to provide an anchor for the popover","2025-05-22T15:04:18Z","https://github.com/nuxt/ui/issues/4013",0.7317385,{"description":2944,"labels":2945,"number":2951,"owner":2859,"repository":2859,"state":2927,"title":2952,"updated_at":2953,"url":2954,"score":2955},"In Nuxt 3, we have introduced a new package `@nuxt/schema` that holds types, defaults, and documentation for all build-in configurations for Nuxt and from one source using [untyped](https://github.com/unjs/untyped). In comparation with Nuxt 2, these were separately maintained, often with inconsistencies. This new system is also designed to be future proof to be able to **manage configuration via UI** using generated (JSON)Schema files and also **runtime validation** to notice any usage issues.\r\n\r\nFor Nuxt modules, it is already possible to extend a typescript interface `ModuleOptions` to provide types, however it has same limitations of Nuxt 2 era. We have introduced new `schema` in new `@nuxt/kit` module definition system however it became unused.\r\n\r\nWith the introduction of Nuxt Layers, themes can also now require some specific configuration. Most importantly for configuring `runtimeConfig` and app config (either via `appConfig` or `app.config`)\r\n\r\nFor this, we can use the same tooling (untyped) as a built-in feature to allow providing custom configuration schemas from Nuxt layers and modules (also directly from a Nuxt project). Benefiting from most possibilities (note 1) we have already for core config.\r\n\r\nWe have made an experiment [nuxt-experiments/nuxt-config-schema](https://github.com/nuxt-experiments/nuxt-config-schema) that is now almost ready to be moved into a core experiment, allowing to make it better usable. It is possible to provide custom config schema for nuxt projects in different ways:\r\n\r\n- Using `nuxt.schema.ts` in main Nuxt project or a layer\r\n- Using `$schema` key in `nuxt.config`\r\n- Extend `nuxt.options.$schema` for modules\r\n- Extend schema using `schema:extend`, `schema:resolved` and `schema:beforeWrite` for modules (note 2)\r\n- Use `schema` in `defineNuxtModule` (recommended way for modules. also supports defaults)\r\n\r\nThe output will be in `.nuxt` directory and initially mainly usable for the Augmentation of types and custom purposes such as UI.\r\n\r\n\r\n**Notes:**\r\n\r\nnote 1: Since development and trial of the experimental module, one particularly important point we found is that, unlike the core usage, mixing schema with defaults is not a good practice. We can only merge schema after modules are setup and it is too late for them to **re**apply new defaults and do their config handling logic and also it makes it much harder to merge runtime configuration such as `app.config` since custom merger logic resides in runtime while schema is in the build-time namespace and merging strategy is different.\r\n\r\nnote 2: We have introduced two separate hooks. `extend`/`resolve` as main way to extend schema just after all modules are initialized and before core or any other place tries to use schema and another `beforeWrite` as last resort (less recommended) for when a module needs to extend schema based on build aftertifacts coming from webpack, rollup or nitro's rollup step and it mainly and only affects the written files.\r\n\r\n\r\n\r\n\r\n\r\n",[2946,2947,2948],{"name":2853,"color":2884},{"name":2886,"color":2887},{"name":2949,"color":2950},"3.x","29bc7f",15592,"Custom config schema","2023-04-07T01:47:49Z","https://github.com/nuxt/nuxt/issues/15592",0.7363874,{"description":2957,"labels":2958,"number":2962,"owner":2859,"repository":2860,"state":2927,"title":2963,"updated_at":2964,"url":2965,"score":2966},"### Description\n\nThe new CheckboxGroup component lacks the `table` variant found on the RadioGroup component. Since these components will often appear together in forms, it would be preferable to have the table variant for both of them.\n\nThis is already easily achieved with the new component by adding the RadioGroup styles to the `item` ui prop. I think it should be possible to make this change just by adding the styles to checkbox-group.ts. I'm happy to make a pull request and make the changes.\n\n### Additional context\n\n_No response_",[2959,2960,2961],{"name":2853,"color":2854},{"name":2873,"color":2874},{"name":2856,"color":2857},3994,"[CheckboxGroup] Add `variant=\"table\"` to match RadioGroup variants","2025-05-13T12:28:16Z","https://github.com/nuxt/ui/issues/3994",0.7409598,{"description":2968,"labels":2969,"number":2973,"owner":2859,"repository":2860,"state":2927,"title":2974,"updated_at":2975,"url":2976,"score":2977},"### 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_",[2970,2971,2972],{"name":2853,"color":2854},{"name":2873,"color":2874},{"name":2856,"color":2857},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.7438627,["Reactive",2979],{},["Set"],["ShallowReactive",2982],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fYRHVZq-x92ZtLVEbrUH3lYM1oasj-yJaLsZFhusZiJE":-1},"/nuxt/ui/4250"]