[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"articles-feed-\u002Fnews-4--":3,"$f2v3tzw7dti6zg":-1},{"items":4,"page":153,"pageSize":154,"totalCount":155},[5,33,49,75,96,116,133],{"content":6,"createdAt":7,"id":8,"image":9,"isAffiliate":10,"isPublished":11,"publishedAt":12,"slug":13,"sourceId":14,"sourceName":15,"sourceType":16,"summary":17,"title":18,"updatedAt":19,"url":20,"urlHash":21,"tags":22},"The place to be for the highly anticipated State of Nuxt for the year 2026. Previous years introduced a new architecture (Nuxt 3), ...","2026-04-17T20:27:43.053Z","019d9d20-c23d-74ce-95cd-60771aa2fe5f","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fwe4gdQikxm8\u002Fhqdefault.jpg",false,true,"2026-04-14T10:00:06.000Z","daniel-roe---state-of-nuxt-2026","019d9ce0-e8f2-774a-ba57-a61c19469fe1","Vuejs Amsterdam","youtube","The article discusses the upcoming State of Nuxt for 2026, highlighting the advancements and changes since the introduction of Nuxt 3. It sets the stage for what to expect in the future of the Nuxt framework.","Daniel Roe - State of Nuxt 2026","2026-04-17T20:27:50.743Z","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=we4gdQikxm8","cc37b2ce2cfc3070e8b7c5f75bcf018590b46fdaa43fa0b42fbb4d9d22719279",[23,27,30],{"color":24,"id":25,"name":26,"slug":26},"#10b981","019d6bd8-fad3-70a9-a74d-ab96e3a2f45d","nuxt",{"color":24,"id":28,"name":29,"slug":29},"019d9cf0-ca04-75bb-ad86-ce8da1c0be23","architecture",{"color":24,"id":31,"name":32,"slug":32},"019d9d20-dfb9-7041-9973-39c545b33a2d","release",{"content":34,"createdAt":7,"id":35,"image":36,"isAffiliate":10,"isPublished":11,"publishedAt":37,"slug":38,"sourceId":14,"sourceName":15,"sourceType":16,"summary":39,"title":40,"updatedAt":41,"url":42,"urlHash":43,"tags":44},"The number 1 annual anticipated update from the Creator of Vue himself, Evan You! You may expect updates like Evan did ...","019d9d20-c23d-74ce-95cd-6569ebec4e77","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fa9_Ud5MFTjU\u002Fhqdefault.jpg","2026-04-13T08:54:41.000Z","evan-you---state-of-vue-2026","Evan You shares insights and updates on the future of Vue in the annual 'State of Vue 2026' address, highlighting key developments and expectations for the framework. This event is highly anticipated by the Vue community as it outlines the direction and innovations in Vue.js.","Evan You - State of Vue 2026","2026-04-17T20:27:50.542Z","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=a9_Ud5MFTjU","6633003842ca2e59cf50193ac27f511c63bd2c17cb4556567d16af5cff1abec9",[45,48],{"color":24,"id":46,"name":47,"slug":47},"019d6bd8-c9a8-7783-bd22-03145b355427","vue",{"color":24,"id":31,"name":32,"slug":32},{"content":50,"createdAt":51,"id":52,"image":53,"isAffiliate":10,"isPublished":11,"publishedAt":54,"slug":55,"sourceId":56,"sourceName":57,"sourceType":58,"summary":59,"title":60,"updatedAt":61,"url":62,"urlHash":63,"tags":64},"Your E2E tests pass. The page loads, buttons work. But open the browser console: Hydration failed because the server rendered HTML didn't match the client. This is a hydration mismatch. The server sent one thing and the client replaced it with something else. The page still works, so you don’t notice. Your tests don’t check for it, so they pass. What are SSR and hydration? SSR (server-side rendering) means the server generates HTML and sends it to the browser before JavaScript loads. Users see content before client code boots, and search engines can index it. Astro and Nuxt build on this model. Hydration is the next step: client JavaScript takes over the server-rendered HTML, attaching event handlers and state to the existing markup. The contract: the first client render must match what the server sent. When it does not match, the framework discards the server HTML and re-renders on the client. That re-render is a hydration mismatch. Common causes Anything that produces different HTML on client and server: Reading localStorage or window.matchMedia() during render Calling new Date() or Math.random() during render Formatting dates or numbers differently across server and client Rendering conditional branches based on browser-only state Theme toggles and locale formatting cause most of them. If you use Vue with SSR, the window is not defined error comes from the same root cause. VueUse has a pattern for it: A real bug I found I was working on an Astro page and my theme hook was reading browser state during the first render: function getInitialTheme(): Theme { const stored = localStorage.getItem(SITE.themeStorageKey); if (stored === \"light\" || stored === \"dark\") return stored; return window.matchMedia(\"(prefers-color-scheme: dark)\").matches ? \"dark\" : \"light\"; } export function useTheme() { const [theme, setTheme] = useState<Theme>(getInitialTheme); } The server defaulted to dark, but the browser picked light. React saw the mismatch, logged a hydration warning, and re-rendered from scratch. The page still worked, the button still existed. Normal E2E tests passed. The fix: start with a deterministic value, resolve browser state after mount. export function useTheme() { const [theme, setTheme] = useState<Theme>(\"dark\"); const [mounted, setMounted] = useState(false); useEffect(() => { const preferredTheme = getPreferredTheme(); document.documentElement.classList.toggle(\"dark\", preferredTheme === \"dark\"); setTheme(preferredTheme); setMounted(true); }, []); useEffect(() => { if (!mounted) return; const root = document.documentElement; root.classList.toggle(\"dark\", theme === \"dark\"); localStorage.setItem(SITE.themeStorageKey, theme); }, [mounted, theme]); return { theme, setTheme, toggleTheme: () => setTheme((t) => (t === \"dark\" ? \"light\" : \"dark\")) }; } The core idea Listen to the browser console during a Playwright test. If a hydration warning appears, fail the test. React and Vue log hydration mismatches to the console. You don’t check the console during automated tests, so this fixture does. The fixture Fixtures are Playwright's way of setting up and tearing down what each test needs. Built-in fixtures like `page` and `browser` come for free. You create custom ones with `base.extend()`. Each fixture runs when a test requests it and gets cleaned up afterward. The fixture below injects `hydrationErrors` and `runtimeErrors` into every test that asks for them. I first saw this approach in the npmx.dev open source project and adapted it for my Astro site. My version covers React and Vue hydration strings and catches uncaught runtime exceptions: const HYDRATION_ERROR_PATTERNS = [ \u002Fhydration failed because the server rendered html didn't match the client\u002Fi, \u002Fhydration completed but contains mismatches\u002Fi, \u002Fhydration text content mismatch\u002Fi, \u002Fhydration node mismatch\u002Fi, \u002Fhydration attribute mismatch\u002Fi, ]; function isHydrationError(text: string): boolean { return HYDRATION_ERROR_PATTERNS.some((pattern) => pattern.test(text)); } function toConsoleText(message: ConsoleMessage): string { return message.text().trim(); } export const test = base.extend<{ hydrationErrors: string[]; runtimeErrors: string[]; }>({ hydrationErrors: async ({ page }, use) => { const hydrationErrors: string[] = []; const handleConsole = (message: ConsoleMessage) => { const text = toConsoleText(message); if (isHydrationError(text)) { hydrationErrors.push(text); } }; page.on(\"console\", handleConsole); await use(hydrationErrors); page.off(\"console\", handleConsole); }, runtimeErrors: async ({ page }, use) => { const runtimeErrors: string[] = []; const handleConsole = (message: ConsoleMessage) => { const text = toConsoleText(message); if (message.type() === \"error\" && text.length > 0 && !isHydrationError(text)) { runtimeErrors.push(text); } }; const handlePageError = (error: Error) => { runtimeErrors.push(error.message); }; page.on(\"console\", handleConsole); page.on(\"pageerror\", handlePageError); await use(runtimeErrors); page.off(\"console\", handleConsole); page.off(\"pageerror\", handlePageError); }, }); export { expect }; Drop this into test\u002Fe2e\u002Ftest-utils.ts and import from there instead of @playwright\u002Ftest. Related: a full AI-driven QA workflow with Playwright: Using it test(\"home page hydrates cleanly\", async ({ page, hydrationErrors, runtimeErrors }) => { await page.goto(\"\u002F\", { waitUntil: \"domcontentloaded\" }); await expect(page.getByRole(\"heading\", { name: \"Home\" })).toBeVisible(); expect(hydrationErrors).toEqual([]); expect(runtimeErrors).toEqual([]); }); Start with your homepage. Add one interactive route, then one with a theme toggle or client-only widget. That surfaces most bugs. How npmx.dev does it at scale The npmx.dev project tests hydration correctness for every combination of user settings across every page, around 48 checks from a single fixture. They inject localStorage values via Playwright’s page.addInitScript() before navigation, simulating a returning user with saved preferences. Returning users with non-default settings trigger most hydration mismatches. const PAGES = [\"\u002F\", \"\u002Fabout\", \"\u002Fsettings\", \"\u002Fcompare\", \"\u002Fsearch\", \"\u002Fpackage\u002Fnuxt\"]; test.describe(\"color mode: dark\", () => { for (const page of PAGES) { test(`${page}`, async ({ page: pw, goto, hydrationErrors }) => { await injectLocalStorage(pw, { \"npmx-color-mode\": \"dark\" }); await goto(page, { waitUntil: \"hydration\" }); expect(hydrationErrors).toEqual([]); }); } }); async function injectLocalStorage(page: Page, entries: Record<string, string>) { await page.addInitScript((e: Record<string, string>) => { for (const [key, value] of Object.entries(e)) { localStorage.setItem(key, value); } }, entries); } They repeat this for every setting type, locale, accent color, background theme, package manager, relative dates, each with a non-default value. If any combination causes a hydration mismatch on any page, the test fails. Their fixture uses Vue-specific error strings (\"Hydration completed but contains mismatches\") while mine uses React patterns. The approach is the same, only the strings you match against change. More on how E2E tests relate to unit and integration tests: If you ship an SSR app and do not check for hydration errors in your browser tests, you have one in production right now.","2026-04-09T06:11:38.114Z","019d70de-1de7-70ea-8344-aded9a900a5c","https:\u002F\u002Falexop.dev\u002Fposts\u002Fhow-to-catch-hydration-errors-in-playwright-tests-astro-nuxt-react-ssr\u002Findex.png","2026-04-06T00:00:00.000Z","how-to-catch-hydration-errors-in-playwright-tests-astro-nuxt-react-ssr","019d70dd-e3e7-76db-84a4-87b896dea004","alexop.dev","rss","The article discusses how to identify and address hydration errors in Playwright tests, particularly in applications using SSR with frameworks like Nuxt and Astro. It explains the concept of hydration mismatches, common causes, and offers solutions to ensure consistent rendering between server and client. The focus is on maintaining a deterministic initial state to prevent hydration warnings during testing.","How to Catch Hydration Errors in Playwright Tests (Astro, Nuxt, React SSR)","2026-04-09T06:11:45.745Z","https:\u002F\u002Falexop.dev\u002Fposts\u002Fcatch-hydration-errors-playwright-tests\u002F","a61a606d501f4750cf6e2136ea2210d1a0550f673021e364846f1ce1953dd9cd",[65,66,69,72],{"color":24,"id":25,"name":26,"slug":26},{"color":24,"id":67,"name":68,"slug":68},"019d6bd8-ca89-735e-a52a-ee53a80a77a9","ssr",{"color":24,"id":70,"name":71,"slug":71},"019d70de-3c07-76bf-9688-9619e1b0d427","testing",{"color":24,"id":73,"name":74,"slug":74},"019d6bd8-ca26-775c-b9b5-c3439dbe5789","performance",{"content":76,"createdAt":77,"id":78,"image":79,"isAffiliate":11,"isPublished":11,"publishedAt":80,"slug":81,"sourceId":82,"sourceName":83,"sourceType":84,"summary":85,"title":86,"updatedAt":87,"url":88,"urlHash":89,"tags":90},"If you have ever built a chat thread, card feed, whiteboard label editor, or masonry layout in Vue, you have probably ended up doing something slightly gross: render text into the DOM, measure it, and then rerender or reposition everything based on that measurement. That works, but it comes with baggage: hidden measurement nodes getBoundingClientRect() and offsetHeight reads in hot paths resize loops that mix layout and app state virtualization code that needs a height before the row is even mounted Pretext is interesting because it attacks that exact problem. Instead of asking the DOM how tall wrapped text became, it prepares the text once and then lays it out against a width using cached measurements. In other words, you can know a text's height before it is even mounted so that Vue can stay focused on state and rendering while Pretext handles the text math. This is not a replacement for Vue, CSS, or the browser layout engine. It is a way to stop using the DOM as your text calculator when all you really need is line count and height. 👉 Don't quite follow? Check out the demo. It breaks down things visually for you. What Pretext actually does The core model is simple: prepare(text, font) does the expensive work once. layout(prepared, width, lineHeight) returns the wrapped height and line count for that width. That split matters. If the text and font stay the same while the available width changes, you do not need to re-measure every grapheme from scratch on every resize. You reuse the prepared value and run layout again. That makes Pretext especially compelling in UI that has lots of text blocks with widths changing over time: virtualized feeds resizable sidebars draggable canvases with labels shrink-wrapped chat bubbles card grids where item height depends on text The Vue angle Vue is already very good at state transitions. The problem is that text measurement traditionally drags you back into imperative DOM work. You start with clean reactive code: const messages = ref<Message[]>([]); Then layout requirements show up and suddenly you are doing things like: await nextTick(); const height = node.getBoundingClientRect().height; That is the line I would try to delete first. With Pretext, the flow looks more like this: Vue owns the text, width, and rendering state. Pretext derives height and line count from text plus width. Your list, grid, or canvas logic consumes those numbers without mounting probe elements first. That is a much cleaner separation of concerns. Install it ni @chenglou\u002Fpretext A simple Vue composable The main trick is to make prepare() depend on the text and font, but not the width. Width changes should only trigger layout(). import { computed, toValue } from "vue"; import { layout, prepare } from "@chenglou\u002Fpretext"; export function usePretextLayout(options) { const text = computed(() => toValue(options.text)); const font = computed(() => toValue(options.font)); const width = computed(() => toValue(options.width)); const lineHeight = computed(() => toValue(options.lineHeight)); const prepared = computed(() => prepare(text.value, font.value)); const result = computed(() => layout(prepared.value, Math.max(1, width.value), lineHeight.value), ); const height = computed(() => result.value.height); const lineCount = computed(() => result.value.lineCount); return { text, font, width, lineHeight, prepared, result, height, lineCount, }; } Why split it this way? Text changes should invalidate the prepared measurement. Font changes should also invalidate it. Width changes should only rerun layout. That maps nicely onto Vue's computed graph. Use it in a component Here is a minimal card example. The width is reactive, but the text measurement does not require mounting a hidden probe element just to discover its height. <script setup lang="ts"> import { ref } from "vue"; import { usePretextLayout } from ".\u002Fcomposables\u002FusePretextLayout"; const body = ref( "Pretext lets Vue apps estimate wrapped text height without measuring hidden DOM nodes first.", ); const cardWidth = ref(320); const font = ref("400 16px Inter, system-ui, sans-serif"); const lineHeight = ref(24); const { height, lineCount } = usePretextLayout({ text: body, font, width: cardWidth, lineHeight, }); <\u002Fscript> <template> <article class="card" :style="{ width: `${cardWidth}px` }"> <p>{{ body }}<\u002Fp> <footer>{{ lineCount }} lines, {{ height }}px tall<\u002Ffooter> <\u002Farticle> <\u002Ftemplate> This is the important mindset shift: the card height is no longer something you discover after the browser lays out the paragraph. It is something you can derive from the same reactive inputs that already describe the UI. Where this gets really useful The simplest demo is a single card, but that is not where the real value is. The real value shows up when the old approach creates layout thrash or architectural awkwardness. 1. Virtualized lists with variable-height text Virtualization loves predictable heights. Text-heavy UIs often do not have them. Pretext gives you a better story: prepare message text when data arrives compute row height from the current column width feed that height into your virtualizer rerun layout when the list width changes That is much better than mounting off-screen rows just to measure them. import { layout, prepare, type PreparedText } from "@chenglou\u002Fpretext"; type Row = { id: string; body: string; prepared: PreparedText; }; const font = "400 15px Inter, system-ui, sans-serif"; const lineHeight = 22; const rows: Row[] = apiRows.map((row) => ({ id: row.id, body: row.body, prepared: prepare(row.body, font), })); function getRowHeight(row: Row, contentWidth: number) { return layout(row.prepared, contentWidth, lineHeight).height + 24; } That pattern fits Vue very naturally. You can prepare once when rows are normalized, then derive heights wherever your layout logic needs them. 2. Chat bubbles that size to content If your message UI wants to make decisions based on line count or wrapped height, Pretext is a cleaner primitive than "render first, inspect later." Examples: deciding whether a bubble gets compact or roomy chrome estimating whether a message should collapse behind "show more" aligning metadata differently for one-line versus multi-line messages Those are layout decisions based on text shape, not business logic. They should not require DOM probes in every component instance. 3. Canvas, whiteboards, and design tools This is where Pretext starts to feel like a category change rather than a small optimization. Its advanced APIs, including prepareWithSegments(), layoutWithLines(), and layoutNextLine(), are designed for cases where you need more than total height: drawing each wrapped line manually finding the widest produced line routing text line by line through changing widths That is useful for labels on canvases, text around shapes, or any UI where the browser is not directly painting the final text layout for you. A practical caveat: your font string has to match reality Pretext is not guessing in the abstract. It measures text against a font declaration and then lays out against a width and line height. That means two values need to match what your UI actually renders: the font string you pass to prepare() the lineHeight you pass to layout() If your component renders with a different font weight, font family, font size, or line height than the values you gave Pretext, your estimated result will drift from the actual DOM layout. So keep the typography source of truth tight. If the component uses: .message { font: 400 16px Inter, system-ui, sans-serif; line-height: 24px; } then your measurement inputs should match those values. What Pretext does not replace This is the part worth being explicit about, because the interesting thing about Pretext is not that it replaces everything. It replaces one very specific pain point. Pretext does not replace: Vue rendering CSS text styling actual width measurement of your container browser selection, caret behavior, or editing UX the browser's final paint of the real text node You still need a width from somewhere. Sometimes that is a prop. Sometimes it comes from your layout model. Sometimes a ResizeObserver is still appropriate. The difference is that you are no longer using the DOM to answer "how tall did this paragraph become?" That is a much smaller and cleaner dependency on layout. When I would reach for it I would consider Pretext when all of these are true: text height or line count affects layout decisions there are many text blocks, or the calculation happens often hidden measurement DOM is making the code awkward or slow you need the answer before mounting the final row or card I would probably not reach for it when: you are rendering a handful of static paragraphs CSS alone solves the problem you only need the browser to lay out the text once and never revisit it In other words, this is not "replace CSS with a library." It is "stop abusing the DOM as a calculator in text-heavy reactive UIs." The broader idea What makes Pretext interesting is not just the API. It is the shift in mental model. For a long time, web developers mostly accepted that wrapped text measurement had to be a DOM problem. Pretext challenges that assumption. In a Vue app, that means some layout decisions that used to live in nextTick(), probe elements, and measurement loops can move back into pure reactive derivation. That is exactly the kind of change I like: not because it is flashy, but because it removes a category of awkward code. Summary Pretext gives Vue developers a better option for text-heavy UI where height and line count matter. You prepare text once, lay it out against width as needed, and stop relying on hidden DOM nodes to tell you what wrapped text looks like.","2026-04-08T06:47:33.045Z","019d6bd8-a30c-720e-b82e-9253cd4d2970","https:\u002F\u002Fblog.vueschool.io\u002Fwp-content\u002Fuploads\u002F2026\u002F04\u002Ffeature-v2-1.jpg","2026-04-03T20:45:27.000Z","using-pretext-in-vue-to-build-variable-height-ui-without-layout-thrash","019d6bd5-87de-77ef-ac92-98aa56cda920","VueSchool","vueschool","The article discusses how to use Pretext in Vue to create variable-height UIs without the common pitfalls of layout thrashing. By preparing text measurements in advance, Pretext allows developers to avoid direct DOM manipulations for height calculations, leading to cleaner and more reactive code. This approach is particularly beneficial for UIs with dynamic text and changing widths.","Using Pretext in Vue to Build Variable-Height UI Without Layout Thrash","2026-04-08T06:47:42.561Z","https:\u002F\u002Fblog.vueschool.io\u002Fvuejs-tutorials\u002Fusing-pretext-in-vue-to-build-variable-height-ui-without-layout-thrash\u002F?friend=MOKKAPPS","75c6e75824a6e8739844c6c1bc511bbf6c5bc3302502ab9c9e1c87376385d07c",[91,92,93],{"color":24,"id":46,"name":47,"slug":47},{"color":24,"id":73,"name":74,"slug":74},{"color":24,"id":94,"name":95,"slug":95},"019d6bd8-ca8b-709c-b9a5-77d4910da162","ui-components",{"content":97,"createdAt":77,"id":98,"image":99,"isAffiliate":11,"isPublished":11,"publishedAt":100,"slug":101,"sourceId":82,"sourceName":83,"sourceType":84,"summary":102,"title":103,"updatedAt":104,"url":105,"urlHash":106,"tags":107},"If you have ever wired up a <label for="…"> to an <input id="…">, duplicated a component twice, and suddenly had duplicate IDs in the document, you already know why “just pick an id string” does not scale. Vue 3.5 added useId(), a small Composition API helper that generates unique-per-application identifiers that stay consistent between server and client renders. Despite the casual phrase “random ids,” useId() is not a source of cryptographic randomness. It produces deterministic, stable strings that are unique within your Vue app instance. That distinction matters: you get uniqueness and SSR safety without Math.random() or global counters that fight hydration. Why useId() exists Manual patterns break down quickly: Hard-coded IDs collide when the same component is used more than once. Math.random() in setup gives different values on server and client, which can cause hydration mismatches in SSR apps. Hand-rolled incrementing counters are easy to get wrong across async boundaries or shared modules. useId() centralizes ID generation in the framework so labels, aria-* attributes, form controls, and more stay valid and predictable. Use Cases for useId() Common situations where you need a DOM-safe unique string (not cryptographic randomness): Creating unique DOM element IDs for anchor links Associating a label and input in a reusable form field component Anchoring headings for in-page navigation (table of contents) Assigning a unique id to custom tooltip or popover elements Distinguishing multiple error callouts or alerts in a single view Generating ids for ARIA attributes (aria-labelledby, aria-describedby, etc.) Marking tab panels and tab buttons with unique relationships Disambiguating ids in nested reusable components (e.g., accordions, tabs) Generating ids for form controls created at runtime (e.g., survey builders) Basic usage Import useId from vue and call it once per logical id you need in the component. Wire the returned string to id, for, or ARIA attributes as usual. <script setup lang="ts"> import { useId } from "vue"; const nameFieldId = useId(); <\u002Fscript> <template> <form> <label :for="nameFieldId">Name<\u002Flabel> <input :id="nameFieldId" type="text" name="name" autocomplete="name" \u002F> <\u002Fform> <\u002Ftemplate> Each call to useId() in the same component instance receives a different id. Each instance of the component receives ids distinct from other instances. That matches what you want for accessible, reusable field groups. Multiple ids in one component Need a pair for email and password? Call useId() separately for each control (or group). <script setup lang="ts"> import { useId } from "vue"; const emailId = useId(); const passwordId = useId(); <\u002Fscript> <template> <div> <label :for="emailId">Email<\u002Flabel> <input :id="emailId" type="email" autocomplete="email" \u002F> <\u002Fdiv> <div> <label :for="passwordId">Password<\u002Flabel> <input :id="passwordId" type="password" autocomplete="current-password" \u002F> <\u002Fdiv> <\u002Ftemplate> SSR and hydration According to the official API docs, ids from useId() are stable across server and client renders. You can use them in Nuxt, custom SSR setups, or any code path that renders on the server first without worrying that the client will “reroll” different strings during hydration. Multiple Vue apps on one page If more than one Vue application mounts on the same document, you can reduce the chance of clashes between apps by setting an id prefix on each app: import { createApp } from "vue"; import AdminRoot from ".\u002FAdminRoot.vue"; const app = createApp(AdminRoot); app.config.idPrefix = "admin"; app.mount("#admin-app"); Use a different prefix per app instance so generated ids remain unique in the combined DOM. Important: do not call useId() inside computed() You should avoid invoking useId() inside a computed() getter. As with other composables, calling it there can cause instance conflicts because id registration is tied to component setup order. Instead, create the id at the top level of <script setup> (or setup()) and close over it inside computeds or methods. <script setup lang="ts"> import { computed, useId } from "vue"; const fieldId = useId(); \u002F\u002F Good: fieldId is fixed for this instance; computed only derives display logic. const describedBy = computed(() => `${fieldId}-hint`); <\u002Fscript> When you might still use something else useId() is extremely useful on the frontend, but it is not the answer for every problem. Here are some cases where you might be tempted to reach for useId() but should not: Entity primary keys from your API—these should be generated by your database or API server Stable keys in v-for when list identity should follow data (prefer a real id from your database model) Correlation IDs for API requests—they should be unpredictable or traceable by policy; use crypto.randomUUID() or server-issued IDs instead of useId() Security-sensitive tokens—use proper random or server-issued secrets For everyday UI plumbing, though, useId() removes a whole class of duplicate-id and SSR bugs with almost no API surface. Summary To sum up, useId() is a powerful tool for generating unique ids for your application. It's a simple, composable API that helps you avoid duplicate-id and SSR bugs with almost no API surface. Uniqueness - Unique per Vue application; distinct for each component instance and on every call SSR - Produces the same id on server and client—safe for hydration Multiple apps - Use app.config.idPrefix to prevent cross-app id collisions when mounting multiple apps PitfallDo - do not call inside computed(); generate the id in setup scope","019d6bd8-a30c-720e-b82e-94ac62042df7","https:\u002F\u002Fblog.vueschool.io\u002Fwp-content\u002Fuploads\u002F2026\u002F04\u002Ffeature-v2.jpg","2026-04-03T17:04:54.000Z","generating-random-ids-in-vuejs","The article discusses the new useId() helper introduced in Vue 3.5, which generates unique identifiers for DOM elements, ensuring consistency between server and client renders. It highlights the importance of unique IDs for accessibility and SSR safety, providing examples of common use cases and basic implementation in Vue components.","Generating Random IDs in Vue.js","2026-04-08T06:47:42.447Z","https:\u002F\u002Fblog.vueschool.io\u002Fvuejs-tutorials\u002Fgenerating-random-ids-in-vue-js\u002F?friend=MOKKAPPS","9174ab0b7d5dd5024c261a80c2b1895cb25c822f78f6b49a83356425d22df98a",[108,109,112,113],{"color":24,"id":46,"name":47,"slug":47},{"color":24,"id":110,"name":111,"slug":111},"019d6bd8-ca21-71c5-a236-37d94fe57d24","composition-api",{"color":24,"id":67,"name":68,"slug":68},{"color":24,"id":114,"name":115,"slug":115},"019d6bd8-caef-76b9-bacd-363e31e6d2a9","accessibility",{"content":117,"createdAt":118,"id":119,"image":120,"isAffiliate":10,"isPublished":11,"publishedAt":121,"slug":122,"sourceId":123,"sourceName":124,"sourceType":58,"summary":125,"title":126,"updatedAt":127,"url":128,"urlHash":129,"tags":130},"Use a typed entry helper to infer props from each component in a component map. This is useful when rendering dynamic blocks from CMS or configuration data.","2026-04-08T06:47:51.870Z","019d6bd8-ec9b-7135-8431-bebca829dd0b","https:\u002F\u002Fmokkapps.twic.pics\u002Fmokkapps.de\u002Fvue-tips\u002Finfer-props-from-component-map\u002Fog.png","2026-03-27T00:00:00.000Z","vue-tip-infer-props-from-components-in-a-component-map","019d6bd5-57e0-742c-8de2-c0a3a1f49b60","Michael Hoffmann","This article discusses how to use a typed entry helper in Vue to infer props from components within a component map. This technique is particularly beneficial for rendering dynamic content from CMS or configuration data.","Vue Tip: Infer Props From Components in a Component Map","2026-04-08T06:47:56.189Z","https:\u002F\u002Fmokkapps.de\u002Fvue-tips\u002Finfer-props-from-component-map","e925088a3bd9b558d6a4787610f1f38c12d1aff89a40454d33e4e0e11bb49f3b",[131,132],{"color":24,"id":46,"name":47,"slug":47},{"color":24,"id":110,"name":111,"slug":111},{"content":134,"createdAt":135,"id":136,"image":137,"isAffiliate":11,"isPublished":11,"publishedAt":138,"slug":139,"sourceId":82,"sourceName":83,"sourceType":84,"summary":140,"title":141,"updatedAt":142,"url":143,"urlHash":144,"tags":145},"RAG (Retrieval-Augmented Generation) is one of the most practical ways to make AI apps useful in the real world. Instead of asking a model to answer from generic training data, you: Index your own documents. Retrieve the most relevant portions of those documents (called "chunks") at query time. Generate an answer grounded in those chunks. In this tutorial, you will build a working Nuxt backend that does exactly that using Google's robust but easy-to-implement RAG solution: Gemini File Search. I'll also provide the frontend UI so you can test the flow end to end. What we are building Server side utility functions for interacting with the Gemini File Search API. Server side utility functions for managing the indexing and asking processes. A Nuxt server endpoint that creates a File Search store. A Nuxt server endpoint that uploads and indexes documents (text from a textarea input) into a Gemini File Search store. A polling endpoint that checks the status of the indexing operation. Another endpoint that queries the store with the File Search tool to answer a question. To best showcase the RAG pipeline in a practical way, I'll also provide you with a simple UI to test things out. This includes: An input field to name your File Search store (auto-generated the first time). A text area to provide plain text documents to upload and index into the store. An input field to ask a question about any of the indexed documents Status updates for the indexing and asking processes. A section to display the answer grounded in the indexed text. I'll also provide you with a page to manage the indexed documents in the store (view and delete them). You can download and run the completed demo app from the GitHub repo. Definition of Relevant RAG Terms Throughout this guide, we will use the following terms related to RAG and the Gemini File Search API. Make sure you understand them before continuing. RAG: Retrieval-Augmented Generation is a technique that uses a large language model to answer questions by retrieving relevant context from a knowledge base. File Search: File Search is a Gemini API that allows you to index and search through your own documents. (aka. a batteries-included RAG pipeline) Chunk: A chunk is a portion of a document that is indexed by the File Search API. Documents are split into these chunks so that the model can retrieve only the most relevant context when answering questions. Store: A store is a collection of documents that are indexed by the File Search API. You can query 1 store at a time. Useful for organizing your documents into logical groups. Tool: A tool is a function that can be called by a language model to perform a task. (in this case, the File Search tool) Prerequisites Node.js and npm installed A Google Gemini API key (you can get one from Google AI Studio here) Step 1) Create a Nuxt App Create a new Nuxt app with the minimal template: npm create nuxt@latest nuxt-rag-app -- -t minimal Then work from your app root: cd nuxt-rag-app All paths in the rest of this guide are relative to that project root. Step 2) Install dependencies (Gemini SDK) ni @google\u002Fgenai @nuxtjs\u002Fmdc @google\u002Fgenai is the Google Gemini API SDK. Alternately you could use the AI SDK as we discuss in our course AI Interfaces with Vue, Nuxt, and the AI SDK. It would make streaming the model output to the frontend a piece of cake. Plus it has other benefits but we're going to keep it simple for this tutorial and forego streaming. Step 3) Expose Your API Key via Nuxt Runtime Config Create a .env file in the root of your project and add your API key: NUXT_GOOGLE_GENERATIVE_AI_API_KEY=your-api-key Then update nuxt.config.ts to expose it via runtime config: \u002F\u002F https:\u002F\u002Fnuxt.com\u002Fdocs\u002Fapi\u002Fconfiguration\u002Fnuxt-config export default defineNuxtConfig({ compatibilityDate: "2025-07-15", devtools: { enabled: true }, modules: ["@nuxtjs\u002Fmdc"], runtimeConfig: { \u002F\u002F this variable name must match the name in the .env file (converted to camelCase and without the NUXT_ prefix) googleGenerativeAiApiKey: "", }, }); Step 4) Add File Search Helper Functions Before we add API endpoints, let's create a set of helper functions in server\u002Futils\u002Fgemini-file-search.ts to manage the File Search operations with Gemini. 1. Import dependencies First, import the required modules. \u002F\u002F server\u002Futils\u002Fgemini-file-search.ts import { GoogleGenAI } from "@google\u002Fgenai"; 2. Helper function to create an authenticated API client Then create a function that initializes the Gemini API client with your API key and handles missing API key errors. \u002F\u002F server\u002Futils\u002Fgemini-file-search.ts function getApiKey() { const runtimeConfig = useRuntimeConfig(); const apiKey = runtimeConfig.googleGenerativeAiApiKey; if (!apiKey) { throw createError({ statusCode: 500, statusMessage: "Missing NUXT_GOOGLE_GENERATIVE_AI_API_KEY .env variable.", }); } return apiKey; } function getClient() { return new GoogleGenAI({ apiKey: getApiKey() }); } 3. Create a File Search store Next, provide a helper function for creating a File Search store. \u002F\u002F server\u002Futils\u002Fgemini-file-search.ts export async function createFileSearchStore(params: { displayName: string }) { const ai = getClient(); const store = await ai.fileSearchStores.create({ config: { displayName: params.displayName, }, }); return store.name ?? ""; } 4. Wait for an asynchronous operation from the API to complete Gemini File Search indexing happens asynchronously. This function polls the operation status until it's done. async function waitForOperation(ai: GoogleGenAI, operation: any) { let current = operation; while (!current.done) { await new Promise((resolve) => setTimeout(resolve, 1000)); current = await ai.operations.get({ operation: current }); } return current; } 5. Upload and index a text document in the store This function uploads your text directly from memory as a Blob, then waits for indexing to finish. export async function uploadTextToStore(params: { fileSearchStoreName: string; content: string; displayName: string; }) { const ai = getClient(); const markdownBlob = new Blob([params.content], { type: "text\u002Fmarkdown" }); const operation = await ai.fileSearchStores.uploadToFileSearchStore({ file: markdownBlob, fileSearchStoreName: params.fileSearchStoreName, config: { displayName: params.displayName, mimeType: "text\u002Fmarkdown", }, }); await waitForOperation(ai, operation); } 6. Ask questions using the indexed File Search context This function sends a question to Gemini, instructing it to answer only using retrieved context from your uploaded files. If Gemini can't answer with the provided context, it will say so. Most importantly, note the usage of the fileSearch tool that gives Gemini access to the indexed documents! export async function askStore(params: { fileSearchStoreName: string; question: string; }) { const ai = getClient(); const groundedQuestion = [ "Answer using only the retrieved File Search context.", 'If the context does not contain the answer, say: "I do not know based on the uploaded documents."', `Question: ${params.question}`, ].join("\\n"); const response = await ai.models.generateContent({ model: "gemini-3-flash-preview", contents: groundedQuestion, config: { \u002F\u002F 👇 this is the key part that gives Gemini access to the indexed documents! tools: [ { fileSearch: { fileSearchStoreNames: [params.fileSearchStoreName], }, }, ], }, }); return { text: response.text ?? "", groundingMetadata: response.candidates?.[0]?.groundingMetadata ?? null, }; } Step 5) Add display-name helper functions After creating the File Search helpers, add one small utility file for generating store and document names. Create server\u002Futils\u002Frag-display-names.ts: \u002F\u002F used if no store name is provided export function createStoreDisplayName() { return `nuxt-rag-store-${Date.now()}`; } \u002F\u002F since we're using a text input instead of an actual document with a filename, we need to generate a unique name for the document we import \u002F\u002F this does that based on the first non-empty line of the content export function createDisplayNameFromContent(content: string) { const firstNonEmptyLine = content .split("\\n") .map((line) => line.trim()) .find((line) => line.length > 0); const base = (firstNonEmptyLine || "notes") .replace(\u002F^#+\\s*\u002F, "") .replace(\u002F[^a-zA-Z0-9\\s-]\u002Fg, "") .trim() .replace(\u002F\\s+\u002Fg, "-") .toLowerCase() .slice(0, 48); return `${base || "notes"}-${Date.now()}`; } Step 6) Add storage and indexing-status helper functions Indexing is asynchronous, so for a better UX we will: create an index job immediately, update job status in KV storage (useStorage()), and poll job status from the frontend. Let's create some helper functions, variables, and types to help manage this process. 1. Define Types and Constants We'll start by defining the job status type, the job object shape, and a key prefix for our storage. \u002F\u002F server\u002Futils\u002Frag-index-jobs.ts import { randomUUID } from "node:crypto"; \u002F\u002F Possible statuses for an indexing job export type RAGIndexJobStatus = "pending" | "succeeded" | "failed"; \u002F\u002F The job object structure export type RAGIndexJob = { id: string; status: RAGIndexJobStatus; fileSearchStoreName: string; displayName: string; createdAt: string; updatedAt: string; errorMessage?: string; \u002F\u002F Populated if failed }; \u002F\u002F Prefix for storing job entries in KV export const INDEX_JOB_PREFIX = "rag:index-job:"; 2. Helpers for Job Storage Keys Next, we need a function to generate a unique storage key for each job based on its ID. export function getJobKey(jobId: string) { return `${INDEX_JOB_PREFIX}${jobId}`; } 3. Creating a New Index Job When we start an indexing operation, we want to create a new job entry in our KV storage with a unique ID and an initial status of "pending". export async function createIndexJob(params: { fileSearchStoreName: string; displayName: string; }) { const job: RAGIndexJob = { id: randomUUID(), status: "pending", fileSearchStoreName: params.fileSearchStoreName, displayName: params.displayName, createdAt: new Date().toISOString(), updatedAt: new Date().toISOString(), }; await useStorage().setItem(getJobKey(job.id), job); return job; } 4. Retrieving a Saved Index Job This function allows you to fetch job details from storage by job ID. export async function getIndexJob(jobId: string) { return await useStorage().getItem<RAGIndexJob>(getJobKey(jobId)); } 5. Marking a Job as Succeeded When an indexing operation completes successfully, use this to update its status. export async function markIndexJobSucceeded(jobId: string) { const existing = await getIndexJob(jobId); if (!existing) return; await useStorage().setItem(getJobKey(jobId), { ...existing, status: "succeeded", updatedAt: new Date().toISOString(), errorMessage: undefined, }); } 6. Marking a Job as Failed If indexing fails, call this to record the failure and the error message. export async function markIndexJobFailed(params: { jobId: string; errorMessage: string; }) { const existing = await getIndexJob(params.jobId); if (!existing) return; await useStorage().setItem(getJobKey(params.jobId), { ...existing, status: "failed", updatedAt: new Date().toISOString(), errorMessage: params.errorMessage, }); } With these helpers in place, you can create, update, check, and manage the lifecycle of document indexing jobs in your app. Step 7) Add API endpoints for stores, indexing, and asking questions Now the API layer can focus on request validation and orchestration while reusing helper functions from server\u002Futils. Let's see how to create the API endpoints for creating stores, indexing documents, and asking questions. 1. Create a store API endpoint Create server\u002Fapi\u002Frag\u002Fstore.post.ts with the following code to support creating a store. export default defineEventHandler(async (event) => { \u002F\u002F get the name of the store from the body const body = await readBody<{ displayName?: string }>(event); const displayName = body.displayName?.trim() || createStoreDisplayName(); \u002F\u002F create the store with the helper function const fileSearchStoreName = await createFileSearchStore({ displayName, }); \u002F\u002F if the store creation failed, throw an error if (!fileSearchStoreName) { throw createError({ statusCode: 500, statusMessage: "Failed to create a File Search store.", }); } \u002F\u002F return the name of the store return { fileSearchStoreName, }; }); 2. Create an indexing API endpoint Create server\u002Fapi\u002Frag\u002Findex.ts with the following code to support indexing a document. export default defineEventHandler(async (event) => { const body = await readBody<{ content?: string; displayName?: string; storeName?: string; }>(event); \u002F\u002F get the content of the document to index \u002F\u002F and the store to index it into \u002F\u002F from the request body const content = body.content?.trim(); const fileSearchStoreName = body.storeName?.trim(); \u002F\u002F if the content is not provided, throw an error if (!content) { throw createError({ statusCode: 400, statusMessage: 'Request body needs a non-empty "content" field.', }); } \u002F\u002F if the store name is not provided, throw an error if (!fileSearchStoreName) { throw createError({ statusCode: 400, statusMessage: 'Request body needs a non-empty "storeName" field.', }); } \u002F\u002F if the display name for the document is not provided, create one from the content const displayName = body.displayName || createDisplayNameFromContent(content); \u002F\u002F and then initialize the indexing job in KV storage const job = await createIndexJob({ fileSearchStoreName, displayName, }); \u002F\u002F create a function to bundle \u002F\u002F - doing the indexing \u002F\u002F - and update the indexing status in KV storage const runIndexing = async () => { try { await uploadTextToStore({ fileSearchStoreName, content, displayName, }); await markIndexJobSucceeded(job.id); } catch (error: any) { await markIndexJobFailed({ jobId: job.id, errorMessage: error?.data?.statusMessage || error?.message || "Unknown indexing error", }); } }; \u002F\u002F Do the indexing in the background event.waitUntil(runIndexing()); \u002F\u002F and return the job id and status immediately with a 202 status code setResponseStatus(event, 202); return { ok: true, accepted: true, jobId: job.id, jobStatus: "pending", fileSearchStoreName, }; }); 3. Create an index-status API endpoint With the indexing API endpoint in place, we can kick off the indexing process but we don't yet have a way to check the status of the indexing job. Let's create an endpoint to do that. Create server\u002Fapi\u002Frag\u002Findex-status.get.ts: export default defineEventHandler(async (event) => { const query = getQuery(event); const jobId = String(query.jobId || "").trim(); \u002F\u002F require the job id to be provided \u002F\u002F we can't check the status of a job if we don't know the job id 🤪 if (!jobId) { throw createError({ statusCode: 400, statusMessage: 'Query string needs a non-empty "jobId" value.', }); } \u002F\u002F get the job from the KV storage const job = await getIndexJob(jobId); \u002F\u002F if the job is not found, throw an error if (!job) { throw createError({ statusCode: 404, statusMessage: "Index job not found.", }); } \u002F\u002F return the job from the KV storage return { job }; }); Great work. You now have the backend flow for indexing documents. Easier than you thought, right? 4. Create an ask API endpoint What's a document index without a way to ask questions about it? Now let's create an endpoint to do that. Create server\u002Fapi\u002Frag\u002Fask.post.ts: export default defineEventHandler(async (event) => { \u002F\u002F get the question from the request body \u002F\u002F and the store of documents to ask the question about const body = await readBody<{ question?: string; storeName?: string }>(event); const question = body.question?.trim(); const fileSearchStoreName = body.storeName?.trim(); \u002F\u002F if the question is not provided, throw an error if (!question) { throw createError({ statusCode: 400, statusMessage: 'Request body needs a non-empty "question" field.', }); } \u002F\u002F if the store name is not provided, throw an error if (!fileSearchStoreName) { throw createError({ statusCode: 400, statusMessage: 'Request body needs a non-empty "storeName" field.', }); } \u002F\u002F use the askStore helper function to ask the question of the File Search store \u002F\u002F You could stream this response, but for simplicity we are not doing that here. const result = await askStore({ fileSearchStoreName, question }); \u002F\u002F The groundingChunks from the File Search API return the context used to answer the question. \u002F\u002F we need to map that to the title, text, and fileSearchStore of the document that was used \u002F\u002F so we can display the attributions in the UI const attributions = (result.groundingMetadata?.groundingChunks ?? []) .map((chunk: any) => chunk?.retrievedContext) .filter(Boolean) .map((ctx: any) => ({ title: ctx.title ?? "Untitled document", text: ctx.text ?? "", fileSearchStore: ctx.fileSearchStore ?? fileSearchStoreName, })); \u002F\u002F that's it! return { answer: result.text, attributions, groundingMetadata: result.groundingMetadata, fileSearchStoreName, }; }); Step 8) Hook up the UI Since this tutorial focuses on the Nuxt backend and Gemini File Search API, you can find the full frontend code in the GitHub repo. Bonus) Add documents management API endpoints The Gemini File Search API also allows you to list and delete documents from a store. While not strictly necessary for our simple app, it's a good way to showcase the full capabilities of the API. And, of course, you'll likely need to list documents or remove a document from a store at some point in your own apps! Let's add those endpoints to the backend. 1) Add document listing and delete helpers Extend server\u002Futils\u002Fgemini-file-search.ts with: \u002F\u002F server\u002Futils\u002Fgemini-file-search.ts export async function listStoreDocuments(params: { fileSearchStoreName: string; }) { const ai = getClient(); const result: Array<{ name: string; displayName: string }> = []; const documents = await ai.fileSearchStores.documents.list({ parent: params.fileSearchStoreName, }); for await (const document of documents as any) { result.push({ name: document.name ?? "", displayName: document.displayName ?? document.name ?? "Untitled document", }); } return result; } export async function deleteStoreDocument(params: { documentName: string }) { const ai = getClient(); await ai.fileSearchStores.documents.delete({ name: params.documentName, config: { force: true }, }); } 2) Add API endpoints Create server\u002Fapi\u002Frag\u002Fdocuments.get.ts: \u002F\u002F server\u002Fapi\u002Frag\u002Fdocuments.get.ts export default defineEventHandler(async (event) => { const query = getQuery(event); const fileSearchStoreName = String(query.storeName || "").trim(); if (!fileSearchStoreName) { throw createError({ statusCode: 400, statusMessage: 'Query string needs a non-empty "storeName" value.', }); } const documents = await listStoreDocuments({ fileSearchStoreName }); return { fileSearchStoreName, documents }; }); Create server\u002Fapi\u002Frag\u002Fdocuments.delete.ts: \u002F\u002F server\u002Fapi\u002Frag\u002Fdocuments.delete.ts export default defineEventHandler(async (event) => { const body = await readBody<{ documentName?: string }>(event); const documentName = body.documentName?.trim(); if (!documentName) throw createError({ statusCode: 400, statusMessage: "Missing documentName", }); await deleteStoreDocument({ documentName }); return { ok: true }; }); And that's it! You now have a backend API for managing your File Search stores, indexing documents, and asking questions. What we've built: Here are the API endpoints provided in this tutorial: 1. List Documents in a File Search Store Endpoint: GET \u002Fapi\u002Frag\u002Fdocuments?storeName=fileSearchStores\u002Fyour-store-name Returns the list of documents stored in the given File Search store. Example Request: curl "http:\u002F\u002Flocalhost:4310\u002Fapi\u002Frag\u002Fdocuments?storeName=fileSearchStores\u002Fyour-store-name" Example Response: { "fileSearchStoreName": "fileSearchStores\u002Fyour-store-name", "documents": [ { "name": "fileSearchStores\u002Fyour-store-name\u002Fdocuments\u002Fdoc-1", "displayName": "My Document" } ] } 2. Delete a Document from a Store Endpoint: DELETE \u002Fapi\u002Frag\u002Fdocuments Send a JSON body with the document's name to delete it from the store. Example Request: curl -X DELETE "http:\u002F\u002Flocalhost:4310\u002Fapi\u002Frag\u002Fdocuments" \\ -H "content-type: application\u002Fjson" \\ -d '{"documentName":"fileSearchStores\u002Fyour-store-name\u002Fdocuments\u002Fdoc-1"}' Example Response: { "ok": true } 3. Create a File Search Store Endpoint: POST \u002Fapi\u002Frag\u002Fstore Creates a new File Search store that will hold your indexed documents. Example Request: curl -s -X POST "http:\u002F\u002Flocalhost:4310\u002Fapi\u002Frag\u002Fstore" \\ -H "content-type: application\u002Fjson" \\ -d '{"displayName":"smoke-test-store"}' Example Response: { "fileSearchStoreName": "fileSearchStores\u002Fabc123" } 4. Upload and Index a Document Endpoint: POST \u002Fapi\u002Frag Uploads text content (as plain text) and indexes it into the specified File Search store. Example Request: curl -s -X POST "http:\u002F\u002Flocalhost:4310\u002Fapi\u002Frag" \\ -H "content-type: application\u002Fjson" \\ -d '{"storeName":"fileSearchStores\u002Fyour-store-name","content":"RAG means Retrieval-Augmented Generation. It retrieves relevant context from your private docs before generation.","displayName":"smoke-test-notes"}' Example Response: { "ok": true, "accepted": true, "jobId": "3f2d41a9-1f2d-43c2-9e21-7f4ce0d3a9b6", "jobStatus": "pending", "fileSearchStoreName": "fileSearchStores\u002Fyour-store-name" } 5. Poll for Indexing Status Endpoint: GET \u002Fapi\u002Frag\u002Findex-status?jobId=... Checks the status of a long-running indexing operation. Example Request: curl -s "http:\u002F\u002Flocalhost:4310\u002Fapi\u002Frag\u002Findex-status?jobId=3f2d41a9-1f2d-43c2-9e21-7f4ce0d3a9b6" Example Response: { "job": { "id": "3f2d41a9-1f2d-43c2-9e21-7f4ce0d3a9b6", "status": "succeeded", "fileSearchStoreName": "fileSearchStores\u002Fyour-store-name", "displayName": "smoke-test-notes" } } 6. Ask Questions Grounded In Your Indexed Docs Endpoint: POST \u002Fapi\u002Frag\u002Fask Sends a natural language question to the backend and gets a grounded answer based on your previously indexed documents. Example Request: curl -s -X POST "http:\u002F\u002Flocalhost:4310\u002Fapi\u002Frag\u002Fask" \\ -H "content-type: application\u002Fjson" \\ -d '{"storeName":"fileSearchStores\u002Fyour-store-name","question":"What does RAG mean?"}' Example Response: { "answer": "RAG means Retrieval-Augmented Generation. It retrieves relevant context from your private docs before generation.", "attributions": [ { "title": "smoke-test-notes", "text": "RAG means Retrieval-Augmented Generation. It retrieves relevant context from your private docs before generation.", "fileSearchStore": "fileSearchStores\u002Fyour-store-name" } ], "groundingMetadata": { \u002F* ... *\u002F }, "fileSearchStoreName": "fileSearchStores\u002Fyour-store-name" } Wrapping up If you enjoyed this article you might also be interested in the comprehensive RAG course over on aidd.io. It goes deep into detail about how RAG works and shows you step by step how to build every part of the process from scratch: from gathering documents, to chunking them, to generating embeddings, to indexing them, and more! You'll also probably want to check out the official docs for Gemini File Search.","2026-04-08T06:47:51.245Z","019d6bd8-ea2a-734b-9c29-2aef0720a232","https:\u002F\u002Fblog.vueschool.io\u002Fwp-content\u002Fuploads\u002F2026\u002F03\u002Fdemo-screenshot.jpg","2026-03-25T23:00:54.000Z","rag-with-nuxt-and-gemini-file-search","This tutorial guides you through building a Nuxt backend that implements Retrieval-Augmented Generation (RAG) using Google's Gemini File Search. You'll learn to create server-side utility functions, manage document indexing, and develop a simple UI for querying indexed documents and displaying answers. The article provides a comprehensive overview of the RAG pipeline along with practical implementation steps.","RAG with Nuxt and Gemini File Search","2026-04-08T06:47:55.039Z","https:\u002F\u002Fblog.vueschool.io\u002Fvuejs-tutorials\u002Frag-with-nuxt-and-gemini-file-search\u002F?friend=MOKKAPPS","cd9445a0fbd730d2ddf9b7b249798a6f5ccabf7741514acd63444f85fdfa6076",[146,147,150],{"color":24,"id":25,"name":26,"slug":26},{"color":24,"id":148,"name":149,"slug":149},"019d6bd8-fb46-77ef-a3b6-bd2d30ab8919","api",{"color":24,"id":151,"name":152,"slug":152},"019d6bd8-fba5-743f-8f9f-4e23c0b31581","tutorial",4,20,67]