`\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.6770702,{"description":1993,"labels":1994,"number":1998,"owner":1985,"repository":1985,"state":1987,"title":1999,"updated_at":2000,"url":2001,"score":2002},"### Describe the feature\n\nI was wondering about the different behavior of `ref()` in a composables file outside of composable function versus the usage in vue component, composable function or pinia for example.\r\n\r\nThe best practice documented here https://nuxt.com/docs/getting-started/state-management which describes `const ref = () => useState(\"key\", () => \"initValue\")` is nice but could be smarter without the additional step to execute this function if i want to use the underlaying ref value.\r\n\r\nuseUseStateSampleComposable.ts - Showcase for the laborious usage of `useState()`\r\n```js\r\nconst useStateFn = () => useState(\"key\", () => \"initValue\");\r\n\r\nexport function useRefSampleComposable(newRefValue: string) {\r\n const refValue = useStateFn() // i hate this additional call\r\n refValue.value = newRefValue;\r\n \r\n return {\r\n refValue\r\n };\r\n}\r\n```\r\n\r\nSo i've built something like this to get an easy workaround where i do not have to execute a function to get the underlaying ref value.\r\n\r\nuseBetterRef.ts - Example solution for doing a \"better ref\".\r\n```js\r\nconst counter = useState(\"useRefCounter\", () => 0); // just for having a unqiue counter id\r\n\r\nexport function useBetterRef(value: string) {\r\n const key = `useRef:${counter.value++}`;\r\n return computed({\r\n get: () => (() => useState(key, () => value))().value,\r\n set: (value) => (useState(key).value = value),\r\n });\r\n}\r\n```\r\n\r\nuseBetterRefSampleComposable.ts - Showcase for the usage of useBetterRef\r\n```js\r\nconst refValue = useBetterRef(\"initValue\");\r\n\r\nexport function useBetterRefSampleComposable(newRefValue: string) {\r\n refValue.value = newRefValue;\r\n \r\n return {\r\n refValue\r\n };\r\n}\r\n```\n\n### Additional information\n\n- [ ] 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).",[1995],{"name":1996,"color":1997},"pending triage","E99695",25911,"ref vs. useState in composables file outside of composable function","2024-06-30T11:05:40Z","https://github.com/nuxt/nuxt/issues/25911",0.72596776,{"description":2004,"labels":2005,"number":2012,"owner":1985,"repository":2013,"state":1987,"title":2014,"updated_at":2015,"url":2016,"score":2017},"### Description\n\nCurrently, when I use `UAvatar` and the user's photo returns a 404, it generates an `\u003Cimg>` with the broken image icon:\n\n\nIs there a way to make the image that returns 404 display text from the alt instead?\nIn the documentation it says:\n>When no icon or text is provided, the initials of the `alt` prop are used as fallback\n\nCan `alt` also be used as a fallback when the image is broken?\n\n\n\nExample:\n\n",[2006,2009],{"name":2007,"color":2008},"question","d876e3",{"name":2010,"color":2011},"v3","49DCB8",3809,"ui","[UAvatar] If the image does not exist, return text","2025-04-06T16:07:33Z","https://github.com/nuxt/ui/issues/3809",0.7285846,{"description":2019,"labels":2020,"number":2027,"owner":1985,"repository":1985,"state":1987,"title":2028,"updated_at":2029,"url":2030,"score":2031},"### 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).",[2021,2024],{"name":2022,"color":2023},"enhancement","8DEF37",{"name":2025,"color":2026},"discussion","538de2",28984,"Real SSR-friendly Ref","2024-09-16T17:51:42Z","https://github.com/nuxt/nuxt/issues/28984",0.7299099,{"description":2033,"labels":2034,"number":2037,"owner":1985,"repository":1985,"state":1987,"title":2038,"updated_at":2039,"url":2040,"score":2041},"### 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).",[2035,2036],{"name":2022,"color":2023},{"name":2025,"color":2026},26306,"adding useManualFetch / usePostFetch / useSubmitFetch composable","2024-06-30T11:05:09Z","https://github.com/nuxt/nuxt/issues/26306",0.730929,{"description":2043,"labels":2044,"number":2048,"owner":1985,"repository":1985,"state":1987,"title":2049,"updated_at":2050,"url":2051,"score":2052},"I believe the Nuxt documentation is rich in explanations and examples, thanks to the contributions of many open-source contributors. However, as the documentation rapidly expands, would it be beneficial to maintain a more consistent structure and ordering of sections? This could improve readability for users and make it easier for contributors to edit and navigate the documentation. \n\nCurrently, I’ve noticed some inconsistencies. For example, the function parameters section is labeled **\"Parameters\"** on some pages but **\"Params\"** on others. Additionally, some pages introduce type definitions at the beginning, while others place them at the end. \n\nWould it make sense to standardize these sections, including their order, to create a more structured and cohesive documentation experience? \n\nBelow are some rough ideas I’ve gathered for a possible structure. Of course, not every page may need all of these sections: \n\n- **Usage**: Explains how to use the function or feature, often including basic examples and common use cases. \n- **Type or Type Declarations**: Defines the TypeScript types related to the function or component, helping users understand expected input and output structures. \n- **Parameters**: Lists and describes the function’s input arguments, including their types, default values, and possible options. \n- **Return Values**: Details what the function returns, including any relevant types, structures, or expected behaviors. \n- **Example**: Provides one or more practical usage examples to demonstrate the function in action. \n\nI'm not sure if this would be helpful, so I’d love to hear your thoughts. If there’s anything I haven’t considered, please feel free to let me know. I really appreciate your feedback! 😊\n",[2045],{"name":2046,"color":2047},"documentation","5319e7",30930,"Standardizing section order in Nuxt documentation for better readability","2025-02-11T17:07:23Z","https://github.com/nuxt/nuxt/issues/30930",0.73218375,{"description":2054,"labels":2055,"number":2056,"owner":1985,"repository":1986,"state":2057,"title":2058,"updated_at":2059,"url":2060,"score":2061},"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.71279085,{"description":2063,"labels":2064,"number":2068,"owner":1985,"repository":2013,"state":2057,"title":2069,"updated_at":2070,"url":2071,"score":2072},"### For what version of Nuxt UI are you suggesting this?\n\nv3.0.0-alpha.8\n\n### Description\n\n```vue\n\u003Cscript setup lang=\"ts\">\ntype Data = {\n id:number,\n name:string\n}\n\nconst defaultData = [\n {\n id: 1,\n name: \"a\"\n },\n {\n id: 2,\n name: \"b\"\n }\n]\n\nconst data = ref\u003CData[]>([])\nconst rerender = () => {\n if (!data.value?.length) {\n data.value = defaultData\n } else {\n data.value = []\n }\n}\n\u003C/script>\n\n\u003Ctemplate>\n \u003Cdiv>\n \u003CUButton label=\"rerender\" @click=\"rerender()\" />\n \u003CUTable :data=\"data\">\n \u003Ctemplate #empty>\n no data\n \u003C/template>\n \u003C/UTable>\n \u003C/div>\n\u003C/template>\n\n````\nIn this example, if the table's data is initially empty and then updated (by clicking the \"rerender\" button), you will notice that the content in the empty slot disappears. This indicates that the table's data is no longer empty, yet nothing is rendered in the table. The reason is that the table's columns are not reactive. I believe this limitation is caused by TanStack.\n\n### Potential Solution\n```vue\nwatch(columns, (newColumns) => {\n tableApi.setOptions((prevOpt) => ({\n ...prevOpt,\n columns: newColumns \n }))\n}) \n```\n\n\n\n\n### Additional context\n\n```vue\n\u003Cscript setup lang=\"ts\">\nimport { watch } from 'vue'\nimport { getCoreRowModel, useVueTable } from '@tanstack/vue-table'\ntype Data = {\n id: number,\n name: string\n}\n\nconst defaultData = [\n {\n id: 1,\n name: \"a\"\n },\n {\n id: 2,\n name: \"b\"\n }\n]\n\nconst data = ref\u003CData[]>([])\nconst columns = computed(() => Object.keys(data.value[0] ?? {}).map((accessorKey: string) => ({ accessorKey, header: accessorKey })))\n\nconst tableApi = useVueTable({\n data,\n columns: columns.value,\n getCoreRowModel: getCoreRowModel()\n})\n\nconst rerender = () => {\n if (!data.value.length) {\n\n data.value = defaultData\n } else {\n data.value = []\n }\n}\n\n/* watch(columns, (newColumns) => {\n tableApi.setOptions((prevOpt) => ({\n ...prevOpt,\n columns: newColumns \n }))\n}) */\n\u003C/script>\n\n\u003Ctemplate>\n \u003Cdiv>\n \u003CUButton label=\"rerender\" @click=\"rerender()\" />\n \u003Cdiv>\n {{ columns }}\n \u003C/div>\n \u003Cbr>\n \u003Cdiv>\n {{ tableApi.options }}\n \u003C/div>\n \u003C/div>\n\u003C/template>\n\n```\n\nnoticed that tableApi's columns won't change along with updates to the data",[2065,2067],{"name":2022,"color":2066},"a2eeef",{"name":2010,"color":2011},2689,"[Table] reactive columns for auto-generated UTable columns","2024-11-21T13:11:03Z","https://github.com/nuxt/ui/issues/2689",0.7152705,{"description":2074,"labels":2075,"number":2078,"owner":1985,"repository":2079,"state":2057,"title":2080,"updated_at":2081,"url":2082,"score":2083},"### Environment\n\n- Operating System: Linux\r\n- Node Version: v18.18.0\r\n- Nuxt Version: 3.9.3\r\n- CLI Version: 3.10.0\r\n- Nitro Version: 2.8.1\r\n- Package Manager: npm@10.2.3\r\n- Builder: -\r\n- User Config: modules, devtools\r\n- Runtime Modules: @pinia/nuxt@0.5.1, @nuxt/test-utils/module@3.10.0\r\n- Build Modules: -\n\n### Reproduction\n\n[Minimal reproduction](https://stackblitz.com/edit/github-ftohct?file=app.nuxt.test.ts)\n\n### Describe the bug\n\nHi all! Do I understand correctly that on the current version of `@nuxt/test-utils` there is no way to pre-fill a store using this instruction from the [Pinia](https://pinia.vuejs.org/cookbook/testing.html#Initial-State) documentation.\r\n\r\n```\r\nimport { describe, test, expect, vi } from 'vitest';\r\nimport { createTestingPinia } from '@pinia/testing';\r\nimport { mountSuspended } from '@nuxt/test-utils/runtime';\r\nimport App from './app.vue';\r\n\r\nconst siteInfoMock = {\r\n title: 'Nuxt 3',\r\n url: 'https://nuxt.com',\r\n};\r\n\r\ndescribe('App link', async () => {\r\n const wrapper = await mountSuspended(App, {\r\n global: {\r\n plugins: [\r\n createTestingPinia({\r\n initialState: {\r\n Site: {\r\n siteInfo: siteInfoMock,\r\n },\r\n },\r\n createSpy: vi.fn,\r\n }),\r\n ],\r\n },\r\n });\r\n\r\n test('Should render the link with a substitute title', () => {\r\n expect(wrapper.get('[data-test-id=\"link\"]').text()).toBe(\r\n siteInfoMock.title\r\n );\r\n\r\n // The test passes because the data in the \"Site\" store has not been changed.\r\n // expect(wrapper.get('[data-test-id=\"link\"]').text()).toBe('Example.com');\r\n });\r\n\r\n test('Should render the link with the spoofed link', () => {\r\n expect(wrapper.get('[data-test-id=\"link\"]').attributes().href).toBe(\r\n siteInfoMock.url\r\n );\r\n\r\n // The test passes because the data in the \"Site\" store has not been changed.\r\n // expect(wrapper.get('[data-test-id=\"link\"]').attributes().href).toBe('https://example.com');\r\n });\r\n});\r\n```\r\nThe component is also rendered, receiving default data from the store. In turn, I expect replacement data in the store.\r\n\r\nI tried to look for information about a similar case in local chats and here in different threads, but I just didn’t receive any information. Several users have raised a similar issue.\r\n\r\n* https://discordapp.com/channels/473401852243869706/1199858451833168004/1199858605831241820\r\n* https://discordapp.com/channels/473401852243869706/496371343542059011/1195669478403489862\r\n* https://discordapp.com/channels/473401852243869706/496371343542059011/1153407426087886942\r\n\r\nIt seems like `@pinia/nuxt` & `@nuxt/test-utils` are not fully compatible, namely the `createTestingPinia` & `mountSuspended` methods.\r\n\r\nPlease tell me, someone was able to solve the problem of how to create a test instance of Pinia.\n\n### Additional context\n\n_No response_\n\n### Logs\n\n```shell-script\nstdout | createSuspenseBoundary (/home/projects/rlmilwjxk.github/node_modules/.pnpm/@vue+runtime-core@3.4.15/node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:1439:43)\r\n\u003CSuspense> is an experimental feature and its API will likely change.\r\n\r\nstderr | warn$1 (/home/projects/rlmilwjxk.github/node_modules/.pnpm/@vue+runtime-core@3.4.15/node_modules/@vue/runtime-core/dist/runtime-core.cjs.js:46:13)\r\n[Vue warn]: App already provides property with key \"Symbol(pinia)\". It will be overwritten with the new value.\n```\n",[2076],{"name":1996,"color":2077},"5D08F5",737,"test-utils","mountSuspended & createTestingPinia","2024-11-28T08:58:33Z","https://github.com/nuxt/test-utils/issues/737",0.71566886,{"description":2085,"labels":2086,"number":2093,"owner":1985,"repository":2094,"state":2057,"title":2095,"updated_at":2096,"url":2097,"score":2098},"at the moment redeploys on cloud providers with `experimental.buildCache` result in font files not being included in published site\r\n\r\n",[2087,2090],{"name":2088,"color":2089},"bug","d73a4a",{"name":2091,"color":2092},"good first issue","7057ff",266,"fonts","support for nuxt `experimental.buildCache`","2024-09-23T14:18:03Z","https://github.com/nuxt/fonts/issues/266",0.719116,["Reactive",2100],{},["Set"],["ShallowReactive",2103],{"TRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"mWsIpGZHF0FfBd6c7CQp2nVXnNO3gemHya3qaaDNk1U":-1},"/nuxt/nuxt.com/490"]