`\n\nUnable to use stroke-width does not take effect",[],364,"nuxt","icon","open","Unable to use stroke-width does not take effect","2025-03-04T02:48:19Z","https://github.com/nuxt/icon/issues/364",0.7383083,{"description":1993,"labels":1994,"number":1995,"owner":1985,"repository":1986,"state":1987,"title":1996,"updated_at":1997,"url":1998,"score":1999},"Hi there!\n\nI've been using the Icon component both personally and at work; I found that when working with local icon collections, the intellisense I get back from the Icon component is lacking compared to the experience I have with Iconify collections.\n\nIf possible I'd like to make a modification that enables type generation for local collections (I already have a good working PR, but it might require some feedback).\n\n",[],359,"Type safe local icon support","2025-02-19T19:13:53Z","https://github.com/nuxt/icon/issues/359",0.76419544,{"description":2001,"labels":2002,"number":2009,"owner":1985,"repository":1985,"state":1987,"title":2010,"updated_at":2011,"url":2012,"score":2013},"### Describe the feature\r\n\r\nNow that I think I understand composables better, especially useFetch, I see myself using it everytime I communicate to my api. Even when posting a form, because I like the out of the box reactive properties it provides.\r\n\r\nAnd now that Nuxt 3.11 adds `clear()` I feel its complete.\r\n\r\nI often end up doing this:\r\n\r\n```js\r\nconst formData = reactive({\r\n firstName: 'Peter',\r\n lastName: 'Griffin',\r\n ...\r\n});\r\n\r\nconst { status, execute: submit, clear, error } = useFetch('...', {\r\n watch: false,\r\n immediate: false,\r\n \r\n body: formData,\r\n method: 'POST',\r\n});\r\n\r\nonBeforeMount(clear); // maybe theres an even better way to automatically clear things up?\r\n```\r\n\r\nI propose to add a new composable, analog to `useLazyFetch`.\r\n\r\nIt could be named `useManualFetch`, `usePostFetch` (`usePost`?) or `useSubmitFetch` (`useSubmit`?)\r\n\r\nAnd it could be used like this:\r\n\r\n```\r\nconst formData = reactive({ ... });\r\nconst { status, error, execute: submit } = useSubmit('...', formData);\r\n```\r\n\r\nMaybe `lazy: true` and `server: false` is also a good default here? I'm not at all familiar enough with SSR and nitro at this point–\r\n\r\nI know I could make (and have made) that composable myself, but I think this is a good thing to offer out of the box to everybody.\r\n\r\nWhat do you think?\r\n\r\n### Additional information\r\n\r\n- [X] Would you be willing to help implement this feature?\r\n- [x] 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).",[2003,2006],{"name":2004,"color":2005},"enhancement","8DEF37",{"name":2007,"color":2008},"discussion","538de2",26306,"adding useManualFetch / usePostFetch / useSubmitFetch composable","2024-06-30T11:05:09Z","https://github.com/nuxt/nuxt/issues/26306",0.7710259,{"description":2015,"labels":2016,"number":2019,"owner":1985,"repository":1985,"state":1987,"title":2020,"updated_at":2021,"url":2022,"score":2023},"### Describe the feature\r\n\r\n### The problem\r\n\r\nSometimes we need a `ref` that works exactly as `ref`, have full semantics and behavior of `ref`, but still works fine with SSR.\r\n\r\nIn the [docs](https://nuxt.com/docs/getting-started/state-management) `useState` is advertised as \"an SSR-friendly `ref` replacement\", which is actually not true as `useState` has different semantics and behavior than `ref` in addition to its SSR-friendliness.\r\n\r\nTo quote the docs:\r\n> [useState](https://nuxt.com/docs/api/composables/use-state) is an SSR-friendly [ref](https://vuejs.org/api/reactivity-core.html#ref) replacement. Its value will be preserved after server-side rendering (during client-side hydration) and shared across all components using a unique key.\r\n\r\nWhat I need is an analogue to `ref` where only the first part of `useState` description (\"Its value will be preserved after server-side rendering\") is true, but not the second (\"shared across all components using a unique key\").\r\n\r\nI.e. that `ref` should be:\r\n1. Initialized **every time** when `script setup` is executed (`init` function of `useState` is not executed on any client-side navigation except the 1st).\r\n2. Preserved between SSR and client-side setup (i.e. hydrated, just like `useState` does).\r\n3. Not shared between component instances or other components (unlike `useState`).\r\n\r\n### The workaround\r\n\r\nCurrently I use workaround like this:\r\n\r\n```ts\r\nconst nuxtApp = useNuxtApp()\r\nconst componentId = useId()\r\nconst myRef = useState(componentId, () => null)\r\nif (!nuxtApp.isHydrating) {\r\n // Called by SSR (initial page load), but also on each client-side navigation too, just as normal ref(generateInitialValue()) would.\r\n myRef.value = generateInitialValue()\r\n}\r\nonUnmounted(() => clearNuxtState(componentId))\r\n```\r\n\r\nI think with the workaround above `myRef` behaves identical to a usual `Ref`, but preserves the value generated by `generateInitialValue()` called from SSR if the component was first rendered by SSR, instead of generating a new initial value (that could be different from SSR-generated value) when the component is rendered on the client.\r\n\r\nAlso, `myRef` is not shared with anyone (even different instances of the same component), just like normal `ref`.\r\n\r\nAnd it's initialization will be performed on each call to `script setup` function, just like normal `ref`. Unlike `useState()`, that calls `init` only 1 time, then `init` is never called again until full server-side reload of the page, that is not what you expect from \"ref replacement\".\r\n\r\nThe downside of this workaround is that on every client-side navigation a new key is created in `useState` data keys storage. So it is a memory leak in this case, as the semantic of `ref` allows to not preserve the value between navigations. It's just a side-effect of using `useState` and `useId` under the hood. I added `onUnmounted(() => clearNuxtState(componentId))`, but this just removes the values, not the keys. Ideally these keys should be removed right after hydration is finished.\r\n\r\n### The proposition\r\n\r\nWhat I want instead is a built-in function that will allow me to write just this:\r\n\r\n```ts\r\nconst myRef = useSsrFriendlyRef(() => generateInitialValue())\r\n```\r\n(the name of the function is discussable, of course 😂)\r\n\r\n### The usefulness\r\n\r\nSuch SSR-friendly `ref` is useful, for example, to generate an initial data to use it as parameters of API called by `useFetch`. These parameters need to be stable between SSR and client-side calling to `useFetch` to make generated fetch key be stable and hydration work.\r\n\r\nOne case when I needed this SSR-friendly `ref` is a component that displays a graph with some data. To load these data from the API the component need to pass a range of dates (e.g. `GET /api/data?from=2024-08-13&to=2024-09-13`). The default (initial) range is \"from 30 days ago to the current date\". After the component is rendered, user should be able to change the range. But on the initial render `useFetch` requests the data for the last 30 days. To make it work properly we need this initial date range to be initialized only once per navigation, but still to be initialized every time the component's setup is called (i.e. the changes user made to `from` and `to` dates should be forgotten if user navigates away from the route and then navigates back). All this behavior is perfectly covered by `ref` except the SSR part. With `ref` the current date could be different in SSR rendered component and client-side rendered component, so the initial date range is different, the `useFetch` key is different, the `useFetch` response hydration doesn't work and `useFetch` is executed 2nd time on the client.\r\n\r\nAnyway, it is just one use-case (maybe not the perfect). The idea of this feature-request is not covering just one use-case, but having a standard mechanism to create SSR-friendly `ref`s, with full semantic of normal `ref`, unlike `useState`, that certainly helpful when you need a shared state, but gets in the way when you need a private state, just like with `ref`, but stable between SSR and client-side rendering.\r\n\r\nI remember `useId()` was introduced not long time ago to cover just a specific case of html element `id` generation (and similar cases). I think it solves similar problem, but in less generic way (you can't use your own initializer, `useId()` always returns a \"random\" string).\r\n\r\nP.S. I tried to search for similar questions/proposition everywhere but didn't find anything. Maybe it's just my skill of creating a correct search requests. :) Anyway, if this idea was already discussed, please point me at it. Honestly, I'm very surprised that it was never discussed, as it is not the first time when I personally needed this feature, just the 1st time when I decided to create a feature request.\r\n\r\n### Additional information\r\n\r\n- [ ] Would you be willing to help implement this feature?\r\n _I would like to, but I'm afraid I will not be able. I tried to understand the implementation of `useId` but it looks like pure black magic to me._\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).",[2017,2018],{"name":2004,"color":2005},{"name":2007,"color":2008},28984,"Real SSR-friendly Ref","2024-09-16T17:51:42Z","https://github.com/nuxt/nuxt/issues/28984",0.77240354,{"description":2025,"labels":2026,"number":2035,"owner":1985,"repository":2036,"state":1987,"title":2037,"updated_at":2038,"url":2039,"score":2040},"### Description\n\nIs there any chance we can get option to enable/disable collapsible when collapsed prop is true. v3.0.0-alpha.13 'fixed' NavigationMenu: disable collapsible with collapsed prop, i used nuxt ui since v3.0.0-alpha.12 and thought the collapsible when collapsed was feature.\n\n### Additional context\n\n_No response_",[2027,2029,2032],{"name":2004,"color":2028},"a2eeef",{"name":2030,"color":2031},"v3","49DCB8",{"name":2033,"color":2034},"triage","ffffff",3353,"ui","NavigationMenu: Option to enable collapsible with collapsed prop","2025-02-27T07:38:30Z","https://github.com/nuxt/ui/issues/3353",0.7732208,{"description":2042,"labels":2043,"number":2044,"owner":1985,"repository":1986,"state":2045,"title":2046,"updated_at":2047,"url":2048,"score":2049},"Ok, so I've followed the instructions here: https://nuxt.com/modules/icon#custom-local-collections\n\nI have my folder in \"assets\", with some icons to test:\n\n\n\nThen I have this in my nuxt.config.ts:\n\n```\nicon: {\n aliases: aliases,\n clientBundle: {\n // list of icons to include in the client bundle\n icons: iconsToBundle,\n\n // scan all components in the project and include icons\n scan: true,\n\n // guard for uncompressed bundle size, will fail the build if exceeds\n sizeLimitKb: 256\n },\n customCollections: [\n {\n prefix: 'nemus',\n dir: './assets/icons'\n }\n ]\n },\n```\n\nAnd it seems to be correctly configured, as I get this message when I run the app:\n\n```\n[1:21:18 PM] ✔ Nuxt Icon loaded local collection nemus with 10 icons\n```\n\nBut when I use one of the icons in a component like this:\n```\n\u003CIcon\n name=\"nemus:trucker-blue\"\n :class=\"['size-4 min-w-4', props.isFav ? 'text-fav ' : 'text-secondary-300']\"\n />\n```\n\nI get this error on the console:\n```\n WARN [Icon] failed to load icon nemus:trucker-blue (repeated 5 times)\n\n\n WARN [nuxt] Failed to stringify dev server logs. Received DevalueError: Cannot stringify arbitrary non-POJOs. You can define your own reducer/reviver for rich types following the instructions in https://nuxt.com/docs/api/composables/use-nuxt-app#payload.\n```\n\nI'm guessing the problem is that I didn't understand this line in the docs:\n```\nNote that custom local collections require you to have a server to serve the API. \n```\n\nIf anyone could shed some light, I'd appreciate it a lot :)",[],355,"closed","Help: can't figure out the server part for custom collections","2025-02-11T13:00:52Z","https://github.com/nuxt/icon/issues/355",0.73648053,{"description":2051,"labels":2052,"number":2056,"owner":1985,"repository":2036,"state":2045,"title":2057,"updated_at":2058,"url":2059,"score":2060},"### Environment\n\n- Operating System: Darwin\n- Node Version: v22.5.1\n- Nuxt Version: 3.13.2\n- CLI Version: 3.13.2\n- Nitro Version: 2.9.7\n- Package Manager: npm@10.8.2\n- Builder: -\n- User Config: compatibilityDate, devtools, app, colorMode, routeRules, runtimeConfig, modules, experimental\n- Runtime Modules: @nuxt/image@1.8.0, @nuxt/ui@2.18.6, @pinia/nuxt@0.5.5\n- Build Modules: -\n\n### Version\n\n\"@nuxt/ui\": \"^2.18.6\",\n\n### Reproduction\n\nhttps://stackblitz.com/edit/nuxt-ui-ajdxeh?file=app.vue,components%2FaddressForm.vue\n\n### Description\n\nhi,\n\nwhen I use the :schema prop to validate the form, the address schema doesn't trigger errors in the form... only the email schema does\n\nif I parse the schema against the formData manual then I can see in the console that it works... get errors and a result if there are no errors...\n\nnot sure if I do something wrong or if i't's a bug...\n\n```js\nimport { z } from 'zod';\nconst formData = ref({\n email: '',\n deliveryAddress: {\n firstName: '',\n lastName: '',\n street: '',\n addressDetails: '',\n city: '',\n country: '',\n postalcode: '',\n },\n});\n\nconst emailSchema = z.object({\n email: z\n .string()\n .min(1, { message: 'E-Mail is required' })\n .email('Invalid email'),\n});\n\nconst addressSchema = z.object({\n firstName: z.string().min(1, { message: 'First Name is required' }),\n lastName: z.string().min(1, { message: 'Last Name is required' }),\n street: z.string().min(1, { message: 'Street is required' }),\n city: z.string().min(1, { message: 'City is required' }),\n country: z.string().min(1, { message: 'Country is required' }),\n postalcode: z.string().min(1, { message: 'Postalcode is required' }),\n});\n\nconst sameAddressSchema = emailSchema.extend({\n deliveryAddress: addressSchema,\n});\n\nconst differentAddressSchema = sameAddressSchema.extend({\n billingAdress: addressSchema,\n});\n\nconst onSubmit = () => {\n try {\n const result = sameAddressSchema.parse(formData.value);\n console.log(result);\n } catch (error) {\n console.log(error);\n }\n};\n\u003C/script>\n\u003Ctemplate>\n \u003CUContainer class=\"min-h-screen flex items-center\">\n \u003CUForm class=\"space-y-8 w-full flex flex-col\" @submit.prevent=\"onSubmit\"> // validates -> check console\n \u003C!-- \u003CUForm class=\"space-y-8 w-full flex flex-col\" :schema=\"sameAddressSchema\" :state=\"formData\" @submit. prevent=\"onSubmit\" ref=\"form\">--> // only validates email, but not the address schema\n \u003CUFormGroup label=\"E-Mail\" required name=\"email\">\n \u003CUInput v-model=\"formData.email\" />\n \u003C/UFormGroup>\n \u003CaddressForm\n v-model:firstName=\"formData.deliveryAddress.firstName\"\n v-model:lastName=\"formData.deliveryAddress.lastName\"\n v-model:street=\"formData.deliveryAddress.street\"\n v-model:addressDetails=\"formData.deliveryAddress.addressDetails\"\n v-model:city=\"formData.deliveryAddress.city\"\n v-model:postalcode=\"formData.deliveryAddress.postalcode\"\n v-model:country=\"formData.deliveryAddress.country\"\n />\n```\n\nthanks,\ngregor\n\n### Additional context\n\n_No response_\n\n### Logs\n\n_No response_",[2053],{"name":2054,"color":2055},"bug","d73a4a",2410,"UForm doesn't show errors with extended/nested zod schemas","2024-10-23T20:23:28Z","https://github.com/nuxt/ui/issues/2410",0.7366028,{"description":2062,"labels":2063,"number":2068,"owner":1985,"repository":2069,"state":2045,"title":2070,"updated_at":2071,"url":2072,"score":2073},"at the moment redeploys on cloud providers with `experimental.buildCache` result in font files not being included in published site\r\n\r\n",[2064,2065],{"name":2054,"color":2055},{"name":2066,"color":2067},"good first issue","7057ff",266,"fonts","support for nuxt `experimental.buildCache`","2024-09-23T14:18:03Z","https://github.com/nuxt/fonts/issues/266",0.7375947,{"description":2075,"labels":2076,"number":2079,"owner":1985,"repository":2080,"state":2045,"title":2081,"updated_at":2082,"url":2083,"score":2084},"",[2077],{"name":2054,"color":2078},"ff281a",490,"nuxt.com","[Content] Fix blog articles sort by date","2022-05-13T16:00:22Z","https://github.com/nuxt/nuxt.com/issues/490",0.7414247,{"description":2075,"labels":2086,"number":2090,"owner":1985,"repository":2080,"state":2045,"title":2091,"updated_at":2092,"url":2093,"score":2094},[2087],{"name":2088,"color":2089},"design","00bd6f",1208,"[Workshop] Workshop single page ","2023-10-10T14:45:09Z","https://github.com/nuxt/nuxt.com/issues/1208",0.74432033,["Reactive",2096],{},["Set"],["ShallowReactive",2099],{"TRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"Rrm7u3HDZTJqEJXBd0ac5i4E01uW8wS7PMHwg9hlZUs":-1},"/nuxt/nuxt.com/1342"]