Key TanStack libraries interview questions and answers

It manages server state: data that lives on a server, can change without you knowing, and must be fetched, cached, deduplicated, refreshed and kept in sync. Instead of hand-written useEffect + useState fetching, you declare a query by key and function and get caching, background refetching, retries, pagination and loading or error states for free.

Each query has a unique queryKey (an array such as ['todos', { page }]). Results are cached by the hashed key; every component using the same key shares one cache entry and one in-flight request. staleTime decides how long data counts as fresh; stale data is still shown instantly and refetched in the background on mount, window focus or reconnect. Unused entries are garbage-collected after gcTime.

staleTime (default 0) is how long fetched data is considered fresh; while fresh, no refetch happens. gcTime (default 5 minutes, called cacheTime before v5) is how long an inactive query (no observers) stays in memory before it is removed. Raising staleTime cuts network traffic; gcTime only controls memory for unused data.

useMutation runs a write and exposes isPending, isError and isSuccess. After success, call queryClient.invalidateQueries({ queryKey: ['todos'] }) to mark matching queries stale and refetch the active ones. Key matching is by prefix, so invalidating ['todos'] also hits ['todos', 1]. Alternatively write the server response straight into the cache with setQueryData.

In onMutate, cancel outgoing refetches with cancelQueries, snapshot the current data with getQueryData, write the expected result with setQueryData and return the snapshot as context. In onError, restore the snapshot. In onSettled, invalidate the query so the cache matches the server. For simple cases v5 also allows rendering variables from useMutation directly while pending.

With refetchOnWindowFocus: true (the default), stale queries refetch when the tab regains focus, keeping data fresh after the user returns. Turn it off or raise staleTime for data that rarely changes or is expensive to fetch, globally in the QueryClient defaults or per query.

Use query key factories per feature: todoKeys = { all: ['todos'], lists: () => [...todoKeys.all, 'list'], list: f => [...todoKeys.lists(), f], detail: id => [...todoKeys.all, 'detail', id] }. Hierarchical keys make invalidation precise and avoid typos.

Each query exposes error and isError for local UI. Use throwOnError (or Suspense with error boundaries) to bubble errors, retry and retryDelay to control retries, and a global QueryCache({ onError }) callback for toasts or logging.

useSuspenseQuery suspends until data is available, so components receive defined data and loading UI comes from <Suspense> boundaries. Errors go to error boundaries; use QueryErrorResetBoundary to retry after an error.

isPending (status pending) means there is no data yet. isFetching is true whenever a request is in flight, including background refetches when data already exists. Show a full skeleton for isPending and a small spinner for isFetching, so cached data stays visible while it refreshes.

A helper that bundles queryKey, queryFn and options into one typed object, shared by useQuery, useSuspenseQuery, prefetchQuery, ensureQueryData and getQueryData. It keeps keys and functions in one place, prevents typos in keys and carries the data type everywhere the key is used.

useInfiniteQuery with queryFn receiving pageParam, a required initialPageParam and getNextPageParam that returns the next cursor or undefined when done. Data arrives as data.pages. Call fetchNextPage when a sentinel enters the viewport (IntersectionObserver), guard with hasNextPage and isFetchingNextPage, and use maxPages or TanStack Virtual for very long lists.

Create a QueryClient per request on the server, prefetch with prefetchQuery, dehydrate the cache into the page and wrap the client tree in HydrationBoundary so it starts filled. Set a staleTime above zero so the client does not refetch immediately. Never share one QueryClient between users on the server.

In onSuccess, use queryClient.setQueryData(['todo', id], updated) to write the server's response into the matching query, avoiding a refetch. For lists, update immutably with a function old => old.map(...).

When new data arrives, TanStack Query keeps the same object references for parts that did not change. Components that select unchanged parts do not re-render, and memoised values stay valid.

Call queryClient.prefetchQuery(options) on hover, in a route loader or before opening a modal. When the component mounts, useQuery with the same key finds the data already cached.

It controls behaviour without a network: online (default) pauses queries while offline, always runs them anyway (for local or mocked data), and offlineFirst tries once then pauses, useful with service-worker caches.

Create a fresh QueryClient per test with retry: false, wrap the component in a provider, mock the network with MSW, and await UI changes with findBy queries. For hooks, use renderHook with a wrapper.

useMutationState({ filters: { status: 'pending' } }) reads mutations from the cache, and useIsMutating() counts them, so you can show global saving indicators or optimistic items from other components.

Dependent: pass enabled: !!userId so the second query waits for data from the first. Parallel: several useQuery calls run in parallel automatically; for a dynamic list use useQueries({ queries: ids.map(id => ({ queryKey: ['item', id], queryFn })) }), optionally with combine to merge the results.

Set placeholderData: keepPreviousData (or previousData => previousData). The old page stays on screen while the new key loads, isPlaceholderData tells you it is stale, and you can disable the Next button until the real page arrives. This replaced v4's keepPreviousData: true option.

The queryFn receives an AbortSignal. Pass it to fetch (or axios) and TanStack Query aborts the request when the query is no longer needed, for example when the component unmounts or the key changes, or when you call cancelQueries.

It polls a query on a timer (for example every 5 seconds), optionally only while the window is focused (refetchIntervalInBackground: false). A function can stop polling when a job completes.

Objects passed to methods such as invalidateQueries, cancelQueries or removeQueries to target queries by key prefix, exact match, type (active or inactive), staleness or a predicate function.

Use PersistQueryClientProvider with a sync storage persister, set gcTime at least as long as maxAge, and use a buster string to drop caches after breaking changes.

Pass defaultOptions: { queries: { staleTime, retry }, mutations: {...} } to the QueryClient, or setQueryDefaults(key, options) for a key prefix, so common settings live in one place.

The Query DevTools list every cache entry with its key, status, observers and data, let you refetch, invalidate, reset or remove queries, and simulate loading and error states during development.

Invalidation marks queries stale and refetches only active ones by default, letting inactive ones refetch when used. refetchQueries refetches matching queries immediately, regardless of staleness.

It transforms or picks part of the cached data for one component, for example select: data => data.filter(t => t.done). The cache keeps the full response; the component re-renders only when the selected result changes. Keep the function stable (outside the component or useCallback) for best performance.

Both cache by key and revalidate. TanStack Query adds mutations with optimistic helpers, infinite queries, devtools, fine-grained cache control, persistence, and adapters for several frameworks; SWR is smaller and simpler.

1. AThe queryKeyCorrect answer
2. BThe fetch URL
3. CA random ID
4. DThe component name

Why: Same key, same cache entry and shared request.

1. A0Correct answer
2. B5 minutes
3. C30 seconds
4. DInfinity

Why: Data is stale immediately unless you raise it.

1. AqueryClient.clear
2. BqueryClient.resetQueries only
3. Crouter.reload
4. DqueryClient.invalidateQueriesCorrect answer

Why: Invalidation is the standard follow-up to a mutation.

1. AmaxAge
2. BgcTimeCorrect answer
3. CstaleTime
4. DkeepTime

Why: It controls garbage collection of inactive queries.

1. AAll queries reset
2. BThe cache clears
3. CStale queries refetchCorrect answer
4. DNothing

Why: refetchOnWindowFocus is true by default.

1. AusePrefetchQuery
2. BuseIsFetching
3. CuseSuspenseQueryCorrect answer
4. DuseQuery

Why: Data is always defined.

1. AprefetchQuery
2. BresetQueries
3. CsetQueryDataCorrect answer
4. DinvalidateQueries

Why: No refetch needed.

1. AusePagedQuery
2. BuseQueries
3. CuseMutation
4. DuseInfiniteQueryCorrect answer

Why: It manages pages and page params.

1. AmaxPages
2. Bselect
3. CinitialPageParamCorrect answer
4. DgetPreviousPageParam

Why: v5 no longer defaults the first page param.

1. AThe query errored
2. BThe query is disabled
3. CNo data exists yet
4. DA request is in flight, including background refetchesCorrect answer

Why: isPending is the no-data state.

1. Asuspense: true
2. Benabled: false (or !!value)Correct answer
3. CstaleTime: 0
4. Dretry: 0

Why: Disabled queries do not run automatically.

1. AConsistent hierarchical keys for precise invalidationCorrect answer
2. BFaster network
3. CSmaller bundles
4. DRequired by v5

Why: One place defines keys.

1. AQueryCache onErrorCorrect answer
2. BEach component only
3. CuseEffect in App
4. DThe service worker

Why: A global callback.

1. ACaches sync across tabs
2. BKeys are shared
3. CUnchanged parts keep the same referencesCorrect answer
4. DData is shared between users

Why: Fewer re-renders.

1. Aretry: falseCorrect answer
2. Bretry: 10
3. CstaleTime: Infinity only
4. DnetworkMode: always only

Why: Failures appear immediately.

1. AuseIsFetching
2. BusePending
3. CuseIsMutatingCorrect answer
4. DuseMutationCount

Why: For global saving indicators.

1. APersists data to localStorage
2. BKeeps the old page shown while the new key loadsCorrect answer
3. CDisables caching
4. DPrefetches every page

Why: isPlaceholderData marks the shown data.

1. ACacheRoot
2. BHydrationBoundaryCorrect answer
3. CQueryProvider
4. DSSRBoundary

Why: It hydrates the dehydrated cache.

1. A0
2. B1
3. C3Correct answer
4. DForever

Why: Three retries with exponential backoff.

1. AA timeout ID
2. BNothing
3. CAn AbortSignalCorrect answer
4. DA Promise

Why: Pass signal to fetch to abort.

1. AretryDelay
2. BrefetchIntervalCorrect answer
3. CpollEvery
4. DstaleTime

Why: Can be a function.

1. Anever
2. BalwaysCorrect answer
3. Conline
4. DofflineFirst

Why: Useful for local data.

1. ACancels queries
2. BRefetches now regardless of stalenessCorrect answer
3. COnly marks stale
4. DRemoves queries

Why: Invalidation is lazier.

1. AsetDefaults
2. BqueryOptions
3. CsetQueryDefaultsCorrect answer
4. DdefaultOptions only

Why: Applies to matching keys.

1. AQueryProvider
2. BQueryErrorResetBoundaryCorrect answer
3. CHydrationBoundary
4. DErrorReset

Why: Resets failed queries.

1. AuseErrorBoundary only
2. Braise
3. ConError
4. DthrowOnErrorCorrect answer

Why: Renamed in v5.

1. AgetQueryData
2. BuseQueries
3. CuseMutationStateCorrect answer
4. DuseMutation

Why: Filter by status.

1. AuseQueryList
2. BuseBatchQuery
3. CuseQueriesCorrect answer
4. DuseInfiniteQuery

Why: It takes an array of query options.

1. ArefetchInterval
2. BgcTimeCorrect answer
3. CstaleTime
4. Dretry

Why: Otherwise data is collected too early.

1. AServer rendering only
2. BMutation helpers, devtools and infinite queriesCorrect answer
3. CNothing
4. DA database

Why: More features, slightly bigger.

End-to-end type safety by inference: paths, path params, search params, loader data and route context are all typed from the route definitions, so a <Link> to a route that does not exist or with a missing param fails type-checking. It also treats search params as validated state, has built-in loaders with caching and preloading, and supports file-based or code-based routes.

A Vite (or other bundler) plugin watches src/routes and generates routeTree.gen.ts. __root.tsx is the root layout, index.tsx an index route, posts.$postId.tsx (or posts/$postId.tsx) a dynamic segment, a leading _ makes a pathless layout route, and each file exports Route = createFileRoute('/posts/$postId')({ ... }).

Create the router with createRouter({ routeTree }) and register it once through module augmentation: declare module '@tanstack/react-router' { interface Register { router: typeof router } }. After that every Link, navigate, useParams and useSearch call is checked against the real route tree.

Each route declares validateSearch (a function or a Zod, Valibot or ArkType schema), so params are parsed, typed and defaulted. Read them with Route.useSearch() and update them with navigate({ search: prev => ({ ...prev, page: prev.page + 1 }) }). Filters, sorting and pagination live in the URL, survive reloads and can be shared.

A route's loader runs before the route renders, in parallel with its parents' loaders, and receives params, context and an abort signal. The result is cached by the router and read with Route.useLoaderData(). Use loaderDeps to declare which search params the loader depends on, so the cache key changes when they do.

Loader results are cached per route and its params and loaderDeps. staleTime decides when cached data is reused without reloading, preloadStaleTime applies to preloads, and gcTime removes unused entries. router.invalidate() marks everything stale and reloads active routes.

Use params.parse and params.stringify on a route to convert and validate path params (for example turning $postId into a number) so loaders and components receive typed, checked values; invalid params can throw notFound().

Use const navigate = useNavigate() then navigate({ to: '/posts/$postId', params: { postId }, search }), or router.navigate outside components. In beforeLoad and loaders, throw redirect({ to }) instead.

Put auth state in router context (createRootRouteWithContext<{ auth: Auth }>() and context on createRouter). In a protected layout route's beforeLoad, check context.auth and throw redirect({ to: '/login', search: { redirect: location.href } }). Every child route then inherits the guard.

Pass the QueryClient in router context. In a loader, call context.queryClient.ensureQueryData(postQueryOptions(id)) to fetch or reuse cached data before rendering, then read it in the component with useSuspenseQuery(postQueryOptions(id)). The router decides when to load; Query owns caching and invalidation. Set router defaultPreloadStaleTime: 0 so Query controls freshness.

With defaultPreload: 'intent' (or preload="intent" on a Link), the router runs the target route's code split chunk and loader when the user hovers or focuses the link, so navigation feels instant. Viewport and render preloading are also available.

With the bundler plugin's autoCodeSplitting, the component, pending and error components are split into lazy chunks automatically while the loader stays in the critical path. Without it, put the lazy parts in a .lazy.tsx file using createLazyFileRoute.

useMatch({ from }) reads the state of a specific matched route (params, loader data, search). useMatchRoute() checks whether a given path is active, for things like highlighting navigation.

<Link> gets data-status="active" and accepts activeProps and inactiveProps (for example a class), with activeOptions: { exact: true } or includeSearch to control matching.

Use useBlocker({ shouldBlockFn: () => isDirty, withResolver: true }) to intercept navigation and show your own confirm dialog, and optionally block browser unload too.

Enable scrollRestoration: true on the router so positions are remembered for back and forward navigation and new pages start at the top; resetScroll on links controls it per navigation.

Validate shared params on a parent route, so children inherit them in useSearch, and use search middlewares such as retainSearchParams or stripSearchParams to keep or remove params during navigation.

A hook that subscribes to the router's state (location, pending matches, status) with a selector, useful for global loading bars or reading the current pathname.

Routes can define pendingComponent (shown after pendingMs while loaders run), errorComponent (receives the error and a reset) and notFoundComponent. Throw notFound() from a loader when a resource does not exist; the nearest not-found boundary renders.

A typed object passed down the route tree: the root gets it from createRouter({ context }), and each route's beforeLoad can return more fields that children receive. It replaces global singletons for things like the QueryClient, the current user or feature flags, and keeps loaders testable.

A parent route renders shared UI and an <Outlet /> where the matched child appears. Pathless layout routes (files starting with _) add a layout or guard without adding a URL segment, and route groups in parentheses only organise files.

Add staticData or loader data with a title to routes, then read all current matches with useMatches() and map them to links.

The typed path params of that route, such as { postId: string }, inferred from the path, so you cannot read a param that does not exist.

Put the component in posts.lazy.tsx with createLazyFileRoute, or rely on automatic code splitting, so the critical route config and loader load first and the component downloads in parallel.

Use the route head option to return title and meta tags per route, rendered with <HeadContent /> in the root, which merges tags from all matched routes.

Create a router with a memory history (createMemoryHistory({ initialEntries: ['/posts/1'] })) and the route tree or a small test tree, render <RouterProvider router={router} /> and await the loaded UI.

Route masking shows a different URL in the browser bar than the real route, for example opening a photo modal over a feed while the address shows the photo's own URL.

Set defaultNotFoundComponent on the router or notFoundComponent on the root route, and throw notFound() from loaders for missing resources.

When routes are generated at runtime, when the bundler plugin is not available, or in small libraries and tests. You build the tree with createRootRoute, createRoute({ getParentRoute, path }) and addChildren, keeping the same type safety.

It supports streaming SSR, dehydrating loader data and hydrating on the client; TanStack Start packages this into a full framework with server functions.

1. AGraphQL support
2. BServer-only routing
3. CCSS-in-JS
4. DFully inferred type-safe routes and search paramsCorrect answer

Why: Types flow from route definitions.

1. AWrap the app in TypeProvider
2. BImport routes into every file
3. CEnable strict mode
4. DRegister it through module augmentationCorrect answer

Why: interface Register { router: typeof router }.

1. AuseQueryString
2. BvalidateSearchCorrect answer
3. CparseQuery
4. DsearchSchema()

Why: It accepts a function or schema library.

1. Arouter.reset()
2. Brouter.invalidate()Correct answer
3. Crouter.refresh()
4. Dwindow.reload()

Why: Marks all matches stale.

1. AuseRedirect
2. BuseGo
3. CuseNavigateCorrect answer
4. DuseHistory

Why: Typed to and params.

1. AloaderDeps
2. BbeforeLoad
3. Cparams.parseCorrect answer
4. DvalidateSearch

Why: Pairs with params.stringify.

1. Aposts/:postId.tsx
2. Bposts.{postId}.tsx
3. Cposts.$postId.tsxCorrect answer
4. Dposts.[postId].tsx

Why: $ marks path params.

1. AIn the component with useEffect
2. BIn the pendingComponent
3. CIn the error boundary
4. DbeforeLoad, by throwing redirect()Correct answer

Why: beforeLoad runs before loaders and rendering.

1. ALoads the route on hover or focusCorrect answer
2. BLoads every route on start
3. CDisables caching
4. DPrefetches images

Why: Code and data load before the click.

1. A_app.tsx
2. Blayout.tsx
3. Cindex.root.tsx
4. D__root.tsxCorrect answer

Why: It wraps every route.

1. AParent routes
2. BQuery client settings
3. CWhich search params the loader depends onCorrect answer
4. Dnpm dependencies

Why: They become part of the loader cache key.

1. AusePrompt
2. BuseBeforeUnload
3. CuseGuard
4. DuseBlockerCorrect answer

Why: Show your own dialog.

1. AcurrentClass
2. BactivePropsCorrect answer
3. CisActive
4. DclassName.active

Why: Also data-status=active.

1. AuseOutlet
2. BuseMatchesCorrect answer
3. CuseRoutes
4. DuseLocation only

Why: Great for breadcrumbs.

1. Arestore
2. BscrollRestorationCorrect answer
3. CkeepScroll
4. DscrollTop

Why: Remembers positions.

1. Awindow.history
2. BhashHistory only
3. CcreateMemoryHistoryCorrect answer
4. DcreateBrowserHistory

Why: Set initial entries.

1. AAn ignored file
2. BA 404 page
3. CA pathless layout routeCorrect answer
4. DA private API route

Why: It wraps children without a URL segment.

1. AuseLoader()
2. BuseRouteData()
3. CuseFetcher()
4. DRoute.useLoaderData()Correct answer

Why: It is typed from the loader.

1. Aredirect('/404')
2. Bthrow notFound()Correct answer
3. Creturn 404
4. Dthrow new Error('404')

Why: The nearest notFoundComponent renders.

1. A<Children />
2. B<Slot />
3. C<RouteView />
4. D<Outlet />Correct answer

Why: Parents render Outlet for nested routes.

1. A<HeadContent />Correct answer
2. B<Head />
3. C<Meta />
4. D<Helmet />

Why: Merges tags from matches.

1. AuseStore
2. BuseMatchRoute
3. CuseRouterStateCorrect answer
4. DuseRouter only

Why: e.g. global loading bars.

1. AcreateFileRoute.lazy
2. BReact.lazy only
3. CcreateLazyFileRouteCorrect answer
4. DlazyRoute

Why: In .lazy.tsx files.

1. ABlocks navigation
2. BShows a different URL than the real routeCorrect answer
3. CHides routes from search
4. DEncrypts params

Why: Used for modals.

1. AretainSearchParamsCorrect answer
2. BkeepSearch
3. CpersistSearch
4. DstickySearch

Why: stripSearchParams removes them.

1. Afallback
2. BerrorComponent
3. CdefaultNotFoundComponentCorrect answer
4. DnotFound404

Why: Or on the root route.

1. AuseLinkStatus
2. BusePath
3. CuseMatchRouteCorrect answer
4. DuseIsActive

Why: Returns params or false.

1. Aroutes.d.ts
2. Brouter.config.ts
3. Cpages.json
4. DrouteTree.gen.tsCorrect answer

Why: It wires file routes into a typed tree.

1. ApreloadStaleTimeCorrect answer
2. BstaleTime only
3. CgcTime
4. DpendingMs

Why: Separate from navigation staleTime.

1. AstaticDataCorrect answer
2. Bcontext only
3. Cparams
4. Dsearch

Why: Read from matches.

A full-stack React (and Solid) framework built on TanStack Router and Vite. It adds server-side rendering with streaming, type-safe server functions callable from the client, server routes for APIs, middleware and deployment to many hosts, while keeping Router's end-to-end type safety for routes, params and search params.

Functions that always run on the server but can be called from the client like a normal async function. You define them with createServerFn({ method: 'GET' | 'POST' }), add an input validator (for example a Zod schema) and a .handler(async ({ data }) => ...). The build replaces the client call with an RPC request, so secrets and database code never reach the browser.

Start is client-first with explicit server boundaries: routes are Router routes, data loads in loaders and server functions, and the build is Vite. Next.js is server-first around React Server Components, file conventions such as page.tsx and layout.tsx, and Turbopack. Start emphasises type-safe routing and search params; Next.js has a larger ecosystem and deeper RSC caching features.

Input is validated by the validator and typed in the handler as data; the handler's return value is serialised and typed on the client. Start's serialiser supports more than JSON, such as Dates and Maps, so callers get the same types back.

Write a server function that reads the database, call it from the route loader (directly or through queryClient.ensureQueryData), and read the result with Route.useLoaderData() or useSuspenseQuery. The first request renders on the server with the data; later navigations call the server function over RPC.

Treat them as public endpoints: authenticate in middleware attached to the function, check authorisation in the handler, validate input, rate-limit sensitive ones and never trust IDs from the client.

Route loaders run on the server during the first SSR request and on the client during later navigations. Because of that, a loader that needs server-only resources calls a server function, which works from both sides. Combined with TanStack Query, loaders prefetch into the cache and components read with useSuspenseQuery.

Reusable logic created with createMiddleware() that runs around server functions or requests: authentication, logging, adding context, validating input. Middleware can run on the client and the server, can pass typed context to the handler, and composes in order.

Routes that handle raw HTTP requests instead of rendering a page, for webhooks, REST endpoints or file downloads. They live alongside page routes and define handlers per method (GET, POST and so on) that return a standard Response.

Routes are fully server-rendered by default. Selective SSR lets a route set ssr: false to render only on the client (for browser-only libraries) or 'data-only' to run the loader on the server but render the component on the client. Static prerendering can generate HTML at build time for chosen pages.

Put it inside server function handlers or server routes, which are compiled out of client bundles, or mark utilities with createServerOnlyFn. For code that must differ per environment use createIsomorphicFn().server(...).client(...). Never import secrets in modules that client components import directly.

Use Start's server helpers to read the request and set response headers or cookies inside the handler, for example to start a session after login.

Loaders can return promises that are deferred and awaited in components with <Await> or Suspense, so the shell renders first and slower data streams in; server functions can also return streams.

Server-only variables are read with process.env inside server code; variables exposed to the client use the Vite prefix (VITE_) and import.meta.env. Keep secrets only in server code.

Register request or function middleware in the Start configuration so it runs for every request or server function, for example logging, authentication context or CSRF protection.

Move routes into TanStack Router file routes, add the Start Vite plugin, convert API calls that need secrets into server functions, and enable SSR route by route with selective SSR for browser-only pages.

Call a POST server function from TanStack Form's onSubmit or a mutation, validate on the server with the same schema, return errors and invalidate affected loaders with router.invalidate() after success.

Call it directly in an event handler or with TanStack Query: useMutation({ mutationFn: (input) => addTodo({ data: input }) }). The useServerFn hook wraps it so redirects and not-found errors thrown on the server are handled by the router.

Read and set cookies in server functions with the built-in request helpers or a session utility, load the current user in the root route's beforeLoad via a server function, put it in router context, and guard protected layout routes by throwing redirect when it is missing.

The production build outputs a server bundle plus static assets. Hosting presets (through Nitro or Vite plugins) target Node.js servers, Vercel, Netlify, Cloudflare and others. Static pages can be prerendered, and SPA mode builds a client-only app.

Throwing in a handler rejects the client call with a serialised error, which you catch in the caller or a route errorComponent. You can also throw redirect() or notFound() from a server function and the router handles them.

__root.tsx renders the HTML document shell: <html>, <head> with <HeadContent />, the body with <Outlet /> and <Scripts />, plus global providers and error boundaries.

Enable prerendering in the Start config with the routes (or crawling) to generate at build time, which suits marketing pages and docs while dynamic pages still render on request.

Use the hosting preset or adapter for that provider; the build outputs functions for server routes and server functions plus static assets, and the platform routes requests to them.

Wrap the call in a server function so the key stays in server environment variables; the client calls the server function, which calls the external API and returns only what the client needs.

Route errorComponents render for loader or render errors on the server and the client; the root error boundary catches the rest. Log server errors in middleware and avoid leaking stack traces to users.

Start is built around client components with explicit server functions and SSR. RSC support has been in development as an addition, so it is not required to use Start.

Marking a utility that must never run on the client; if client code calls it, it throws, preventing accidental use of server-only code in the browser.

Vite is the dev server and bundler: fast HMR, its plugin ecosystem and its environment API to build client and server bundles. Start is a set of Vite plugins plus Router, so most Vite plugins and configuration work unchanged.

For SEO and faster first paint with SSR, for keeping secrets and database access on the server via server functions, and for one deployable full-stack app.

1. ANext.js and Webpack
2. BRemix and esbuild
3. CExpress and Babel
4. DTanStack Router and ViteCorrect answer

Why: Router provides routing; Vite builds it.

1. AdefineAction
2. BserverAction()
3. CcreateServerFnCorrect answer
4. DuseServer

Why: It compiles to an RPC call on the client.

1. AAlways on the serverCorrect answer
2. BAlways in the browser
3. CWherever it is called
4. DOnly at build time

Why: The client only sends an RPC request.

1. APublic endpoints needing auth and validationCorrect answer
2. BPrivate code nobody can call
3. CClient-only helpers
4. DBuild scripts

Why: Anyone can send an RPC request.

1. ACookies
2. BThe database
3. CVITE_-prefixed vars via import.meta.envCorrect answer
4. DAll process.env vars

Why: Keep secrets server-only.

1. A<Slot />
2. B<Outlet />Correct answer
3. C<Children />
4. D<Main />

Why: Inside the document body.

1. Acsr: true
2. Bclient: only
3. Crender: 'spa'
4. Dssr: falseCorrect answer

Why: Selective SSR per route.

1. ADisables loaders
2. BPrerenders at build time
3. CStreams only JSON
4. DRuns the loader on the server, renders the component on the clientCorrect answer

Why: Data is fetched during SSR; UI renders in the browser.

1. AcreateMiddlewareCorrect answer
2. BuseMiddleware
3. Capp.use
4. DdefineGuard

Why: Middleware composes and passes typed context.

1. AOnly in the browser
2. BOnly at build time
3. COn the server for the first request and on the client for later navigationsCorrect answer
4. DOnly on the server

Why: They are isomorphic.

1. AA standard ResponseCorrect answer
2. BJSX
3. CA Router object
4. DA QueryClient

Why: They handle raw HTTP.

1. A<Script />
2. B<Bundle />
3. C<Body />
4. D<Scripts />Correct answer

Why: Rendered in __root.tsx.

1. AUse polling
2. BUse iframes
3. CReturn deferred promises awaited with SuspenseCorrect answer
4. DBlock until all data loads

Why: The shell renders first.

1. AqueryClient.clear()
2. BNothing
3. Crouter.invalidate()Correct answer
4. Dlocation.reload()

Why: Reloads active route data.

1. AIn VITE_ variables
2. BIn localStorage
3. CInside a server functionCorrect answer
4. DIn a client component

Why: It never reaches the browser.

1. AIt runs on the client
2. BIt is ignored
3. CIt calls the server
4. DIt throwsCorrect answer

Why: Prevents accidental misuse.

1. AisServer()
2. BcreateIsomorphicFnCorrect answer
3. CcreateServerOnlyFn
4. DuseServerFn

Why: It takes .server() and .client() implementations.

1. AuseRpc
2. BuseFormState
3. CuseServerFnCorrect answer
4. DuseAction

Why: Router handles thrown redirects.

1. AIt cannot be validated
2. BOnly on the client
3. CWith an input validator such as a Zod schemaCorrect answer
4. DWith PropTypes

Why: Validation runs on the server before the handler.

1. AViteCorrect answer
2. BWebpack
3. CTurbopack
4. DParcel

Why: Start is a set of Vite plugins.

1. AReal-time chat
2. BMarketing and docs pagesCorrect answer
3. CUser dashboards
4. DCheckout pages

Why: Content that rarely changes.

1. AOnly numbers
2. BFunctions
3. CDates and Maps, not just JSONCorrect answer
4. DOnly strings

Why: Types survive the round trip.

1. AOnly on the client
2. BOnce at build
3. CFor every request or server functionCorrect answer
4. DOnly in development

Why: Registered in Start config.

1. AnotFoundComponent
2. Bhead
3. CerrorComponentCorrect answer
4. DpendingComponent

Why: On server and client.

1. ARequired for every route
2. BForbidden
3. CIts only rendering mode
4. DAn optional addition, not requiredCorrect answer

Why: Client components plus server functions.

1. ARenders an empty page
2. BOnly downloads JS
3. CRedirects
4. DRenders on the server with loader dataCorrect answer

Why: Then hydrates.

1. AThey cannot
2. BServer functions over RPCCorrect answer
3. CFull page reloads
4. DWebSockets only

Why: Client-side navigation.

1. AA native app
2. BA server-only API
3. CA client-only app without SSRCorrect answer
4. DA static blog

Why: Useful for hosts without a server runtime.

1. ASSR, server functions and one deployable appCorrect answer
2. BSmaller bundles always
3. CNo JavaScript
4. DNo routing

Why: SEO and secrets on the server.

1. A__root.tsxCorrect answer
2. Bindex.html only
3. Cdocument.tsx
4. Dapp.html

Why: Rendered by Start.

It ships no markup or styles: it computes header groups, rows, cells and feature state, and you render them with your own <table>, divs or a design system. That gives full control over look and accessibility, works in any framework through adapters, and keeps the core small, at the cost of writing the rendering yourself.

Define columns (with createColumnHelper<Row>() accessors, headers and cells), keep data and columns referentially stable, and call useReactTable({ data, columns, getCoreRowModel: getCoreRowModel() }). Render table.getHeaderGroups() for headers and table.getRowModel().rows with row.getVisibleCells(), using flexRender for header and cell templates.

The table recomputes row models when they change. Creating a new array on every render (inline [] or columns defined in the component without useMemo) makes it recompute on every render and can cause an infinite re-render loop. Define columns outside the component or memoise them, and memoise or store data in state.

Client-side: add getSortedRowModel, getFilteredRowModel and getPaginationRowModel and the table does the work on loaded data. Server-side: set manualSorting, manualFiltering and manualPagination, pass rowCount (or pageCount), control the state, and send it to the API (often with TanStack Query) to fetch the right page.

Control pagination and sorting state, include them in the query key, fetch with useQuery and placeholderData: keepPreviousData, pass data, rowCount and manualPagination: true / manualSorting: true to the table, and render page controls from table.getCanPreviousPage() and friends.

Render inputs in cell renderers, keep edits in local state per cell, and on blur call an update function passed through meta (table.options.meta.updateData(rowIndex, columnId, value)) that updates your data immutably or triggers a mutation.

Define the row type, use createColumnHelper<Row>() so accessors are checked against the row's keys, and type ColumnDef<Row>[]. Custom meta can be typed by augmenting TableMeta and ColumnMeta interfaces.

Pass slices to state (for example state: { sorting, pagination }) and handlers such as onSortingChange: setSorting. Controlled state lets you sync with the URL, persist preferences or trigger fetches. Use initialState for defaults you do not need to control.

Enable it with enableRowSelection (or a function per row), control rowSelection state, and render checkboxes with row.getIsSelected(), row.getToggleSelectedHandler() and table.getToggleAllPageRowsSelectedHandler(). Set getRowId to a stable id so selection survives sorting and refetches.

Combine Table with TanStack Virtual: Table produces the row model and useVirtualizer renders only the rows in the viewport plus overscan, with spacer padding for the rest. Keep cells light, memoise expensive renderers and prefer server-side pagination if users do not need all rows at once.

columnHelper.accessor('price', { cell: info => format(info.getValue()) }) reads a field; accessor(row => row.first + ' ' + row.last, { id: 'name' }) derives a value and needs an explicit id. columnHelper.display({ id: 'actions', cell: ... }) adds columns without data, such as buttons.

Enable column pinning, control columnPinning state { left: ['select'], right: ['actions'] }, render left, center and right cells with row.getLeftVisibleCells() and friends, and use sticky CSS with offsets from column.getStart('left').

Set enableColumnResizing and columnResizeMode: 'onChange' or 'onEnd', use header.getResizeHandler() on a drag handle and header.getSize() or CSS variables for widths. For performance with many columns, set widths through CSS variables.

Provide getSubRows: row => row.children for hierarchical data, add getExpandedRowModel, control expanded state and render a toggle with row.getToggleExpandedHandler() and indentation from row.depth. You can also render custom detail panels for expanded rows.

Set sortingFn on a column to a built-in (alphanumeric, datetime, basic) or your own (rowA, rowB, columnId) => number, and use sortUndefined and sortDescFirst to control edge cases.

Read the rows you want (table.getFilteredRowModel().rows or selected rows), map visible columns to values with row.getValue(column.id), build CSV text with proper escaping and download it as a Blob.

Group columns with columnHelper.group({ header: 'Name', columns: [...] }); table.getHeaderGroups() returns rows of headers with colSpan and placeholders, which you render as multiple header rows.

Sorting (multi-column), column and global filtering, faceting, pagination, grouping and aggregation, expanding (sub-rows), row selection, column visibility, ordering, pinning and sizing or resizing, all opt-in through row models and options.

Column filters apply per column (column.setFilterValue) with a filterFn such as includesString or a custom one. The global filter searches across columns with one value (setGlobalFilter). Faceted row models give unique values and min-max ranges for building filter UIs.

Render real <table>, <thead>, <th scope="col"> and <tbody> elements, put sort controls in buttons inside headers and set aria-sort, label selection checkboxes, announce page changes, and keep keyboard focus order sensible when rows change.

Control columnVisibility and columnOrder state with their change handlers, save them to localStorage or the user profile, and restore them as initial state. Use column.getToggleVisibilityHandler() for menus.

Arbitrary data and callbacks attached to the table (options.meta) or a column (columnDef.meta), such as update functions, alignment or formatting hints, accessible inside cells and headers.

Set footer on columns as a function that computes totals from table.getFilteredRowModel().rows, and render table.getFooterGroups() in a <tfoot>.

Call table.resetSorting(), resetColumnFilters(), resetPagination() and similar, or table.reset() for everything, returning to initialState.

By default, pagination resets when data changes; set autoResetPageIndex: false when updating rows in place (such as edits) so users stay on their current page.

Add a custom filterFn using a ranking library like match-sorter-utils' rankItem, store the rank in addMeta, and optionally sort by rank, giving forgiving search across columns.

When you need full control over markup, styling and accessibility, or to match a design system. Full data grids (AG Grid, MUI Data Grid) give ready-made UI and advanced features at the cost of flexibility and bundle size.

The API is the same: render header groups and rows as divs with CSS grid or flex, and add ARIA roles (role="table", row, columnheader, cell) so screen readers understand the structure.

Set grouping state to column ids and add getGroupedRowModel and getExpandedRowModel. Each column can set aggregationFn (sum, count, mean and more) and aggregatedCell to show totals on grouped rows.

v9 has been in development with a more modular feature system for smaller bundles and better performance. Check the docs before adopting pre-release versions.

1. AgetCoreRowModelCorrect answer
2. BgetSortedRowModel
3. CgetPaginationRowModel
4. DgetFilteredRowModel

Why: It builds the base rows.

1. ANo TypeScript
2. BNo built-in markup or stylesCorrect answer
3. CNo JavaScript
4. DServer-only

Why: You render the UI yourself.

1. AgetSortedRowModelCorrect answer
2. BuseSort
3. CsortRows()
4. DcreateSorter

Why: Row models add features.

1. AThe table instance
2. BNothing
3. CPagination and sorting stateCorrect answer
4. DThe column definitions

Why: New state, new fetch.

1. AThrough table.options.metaCorrect answer
2. BThrough window
3. CThrough props drilling only
4. DThrough CSS

Why: meta carries callbacks.

1. ATableColumn
2. BHeader<Row>
3. CCellDef
4. DColumnDef<Row>Correct answer

Why: Generic over the row type.

1. AUsing flexRender
2. BEnabling sorting
3. CUsing TypeScript
4. DCreating data or columns inline on every renderCorrect answer

Why: Keep references stable.

1. AserverPagination
2. BremotePages
3. Cpaginate: 'server'
4. DmanualPaginationCorrect answer

Why: Pair it with rowCount or pageCount.

1. ArenderCell
2. Btable.render
3. CcreateElement only
4. DflexRenderCorrect answer

Why: It handles strings, components and functions.

1. AAn explicit idCorrect answer
2. BA header image
3. CA filterFn
4. DA footer

Why: There is no key to derive the id from.

1. ATanStack Start
2. BTanStack VirtualCorrect answer
3. CTanStack Form
4. DTanStack Store

Why: It renders only visible rows.

1. AcolumnVisibility
2. BcolumnPinningCorrect answer
3. CcolumnOrder
4. DcolumnSizing

Why: Render with sticky CSS.

1. AuseResize
2. Btable.drag
3. Cheader.getResizeHandler()Correct answer
4. Dcolumn.resize()

Why: Attach to a handle.

1. AgetChildren
2. BsubRowsKey
3. Cnested
4. DgetSubRowsCorrect answer

Why: With getExpandedRowModel.

1. Atext
2. Bbasic only
3. CdatetimeCorrect answer
4. Dalphanumeric

Why: Set as sortingFn.

1. AcolumnHelper.groupCorrect answer
2. BcolumnHelper.merge
3. CheaderGroup()
4. DcolSpan only

Why: Multiple header rows.

1. ATo sort rows
2. BTo style rows
3. CTo paginate
4. DTo keep row identity stable across sorts and refetchesCorrect answer

Why: Selection and expansion use row ids.

1. AcolumnPinning
2. BcolumnVisibilityCorrect answer
3. CcolumnFilters
4. DhiddenColumns

Why: Toggle with column.toggleVisibility.

1. AcolumnHelper.group only
2. BcolumnHelper.virtual
3. CcolumnHelper.displayCorrect answer
4. DcolumnHelper.accessor

Why: Used for actions and checkboxes.

1. AgetFacetedUniqueValuesCorrect answer
2. BgetCoreRowModel
3. CgetExpandedRowModel
4. DgetGroupedRowModel

Why: Faceting powers filter UIs.

1. AkeepPage: true
2. BmanualPagination
3. CpageIndex: 0
4. DautoResetPageIndex: falseCorrect answer

Why: Pagination resets by default.

1. AIn the header
2. BIn meta
3. CIn a cell only
4. DgetFooterGroups in a tfootCorrect answer

Why: Footer functions compute them.

1. Atable.clear()
2. Btable.init()
3. Ctable.destroy()
4. Dtable.reset()Correct answer

Why: Back to initialState.

1. Amatch-sorter-utilsCorrect answer
2. Blodash only
3. Cfuse-lite
4. Dregex

Why: Its rankItem scores fuzzy matches.

1. AgetSortedRowModel
2. BgetExpandedRowModelCorrect answer
3. CgetCoreRowModel
4. DgetGroupedRowModel

Why: Required for sub-rows.

1. AWhen ready-made UI matters more than controlCorrect answer
2. BNever
3. CFor tiny tables only
4. DWhen using TypeScript

Why: Trade flexibility for features.

1. Atable, row, columnheader, cellCorrect answer
2. Blist and listitem
3. Cgrid only
4. Dnone needed

Why: Expose structure.

1. AaggregationFnCorrect answer
2. BsumFn
3. CgroupBy
4. DfooterFn

Why: Aggregation runs per group.

1. Adrag
2. BonChangeCorrect answer
3. ConEnd
4. Dlive

Why: onEnd updates on release.

1. AsortOrder
2. BsortDescFirstCorrect answer
3. Cdescending
4. DreverseSort

Why: Per column or table.

A headless, type-safe form library for React, Vue, Angular, Solid, Svelte and Lit. Field names and values are inferred from defaultValues, so a typo in a field name is a type error. It has flexible sync and async validation, Standard Schema support, array fields and fine-grained subscriptions so only the fields that change re-render.

Create it with useForm({ defaultValues, onSubmit: async ({ value }) => save(value) }). Render each field with <form.Field name="email" children={field => <input value={field.state.value} onChange={e => field.handleChange(e.target.value)} onBlur={field.handleBlur} />} />, and call form.handleSubmit() from the form's submit handler after preventDefault.

Validators can be set per field or on the whole form, under validators with keys onChange, onBlur, onSubmit, onMount and async versions such as onChangeAsync (with onChangeAsyncDebounceMs). A validator returns an error message (or object) or undefined. Errors appear in field.state.meta.errors, and canSubmit turns false while any are present.

It supports Standard Schema directly: pass a schema as a validator, for example validators: { onChange: z.string().email() } on a field or validators: { onSubmit: userSchema } on the form. No adapter package is needed in v1, and form-level schema errors are mapped to the matching fields.

Make onSubmit async; the form tracks isSubmitting while the promise runs. Read it through form.Subscribe to disable the button and show progress, and handle server errors by setting field or form errors.

After a failed submit, set form-level errors through the onSubmitAsync validator's return value (mapping messages to fields), or call form.setFieldMeta / field APIs to set errors on specific fields so they appear next to inputs.

Keep one form instance for all steps, render only the current step's fields, validate the step's fields before moving on (form.validateField or validating a subset), and submit once at the end; or use one form per step and merge results.

State lives in a TanStack Store, and each form.Field or form.Subscribe subscribes only to the slice it needs. Typing in one field updates that field's subscribers rather than the whole form tree, which keeps large forms fast.

Rendering UI from form state without re-rendering the whole form: <form.Subscribe selector={s => [s.canSubmit, s.isSubmitting]} children={([canSubmit, isSubmitting]) => <button disabled={!canSubmit}>{isSubmitting ? 'Saving…' : 'Save'}</button>} />.

Render a field with mode="array" and map over field.state.value, rendering sub-fields named like people[${i}].name. Use field.pushValue, removeValue, insertValue, moveValue and swapValues to change the list; types still flow to every sub-field.

Use onChangeListenTo: ['password'] on the confirm field so its validator re-runs when the password changes, and read the other value with fieldApi.form.getFieldValue('password') inside the validator. Field listeners can also react to changes, for example resetting a dependent field.

Use createFormHook with createFormHookContexts to register reusable field components (TextField, Select) and form components (SubmitButton). It returns useAppForm, and fields render as <form.AppField name="email" children={f => <f.TextField label="Email" />} />, keeping type safety while removing boilerplate.

Field validators check one value and attach errors to that field. Form validators see all values, suit cross-field rules, and can return errors per field through an object keyed by field name, or a general form error.

Wrap UI inputs (shadcn, MUI, Chakra) in field components that take field.state.value, field.handleChange and field.handleBlur, and show field.state.meta.errors. createFormHook registers them once for reuse.

Fields accept listeners: { onChange: ({ value }) => ... } to react to changes, such as resetting a dependent field (clear the city when the country changes) without putting that logic in validators.

Use onChangeAsync with onChangeAsyncDebounceMs: 500, return an error if the name is taken, and show field.state.meta.isValidating as a small spinner.

Field names support dot and bracket paths (address.city, tags[0]). For checkbox groups, use an array field and toggle values with pushValue and removeValue, or set the whole array with handleChange.

Pass the form instance down or use withForm from createFormHook to build sections that receive a typed form, keeping large forms split into readable components.

field.state.meta includes errors, errorMap (errors by validation cause), isTouched, isBlurred, isDirty, isPristine and isValidating. A common pattern is to show errors only when isTouched is true.

Validate again on the server; never trust client checks. With TanStack Start or Next.js, the server helpers (such as createServerValidate) run the same validators, return errors in a form state, and mergeForm with useTransform merges them back into the client form.

Pass loaded data as defaultValues (render the form after the data loads, or key it by record id), call form.reset() to return to defaults, or form.reset(newValues) to set new defaults, for example after a successful save.

It is false while there are errors from validators that have run, or while the form is submitting; you can choose to allow submit on untouched forms so validation runs on submit.

Call form.reset() in onSubmit after the request succeeds, optionally with new values as the new defaults.

Render the form with Testing Library, type with user-event, blur fields to trigger validation, assert error messages by role or text, and assert the submit handler receives typed values.

Use form.Subscribe with a selector on values.fieldName, or useStore(form.store, state => state.values.fieldName), so only that part re-renders.

The user has interacted with the field (changed it). Many apps show errors only after touch or after a submit attempt, so untouched fields stay clean.

The Next.js adapter provides helpers to validate on the server inside a server action with the same validators and to merge the resulting state into the client form with useActionState.

Validation that runs as soon as the field or form mounts, useful for pre-filled data that may already be invalid.

React Hook Form is mature, popular and leans on uncontrolled inputs. TanStack Form uses controlled fields with fine-grained subscriptions, deeper type inference for nested and array field names, built-in async debounce and works across many frameworks. Both support schema validation.

React, Vue, Angular, Solid, Svelte and Lit through adapters over the same core, so form logic and validators can be shared conceptually.

1. AuseFormCorrect answer
2. BuseFormState
3. CcreateForm only
4. DuseFields

Why: useForm({ defaultValues, onSubmit }).

1. AA separate .d.ts file
2. BPropTypes
3. CThe HTML input type
4. DInferred from defaultValuesCorrect answer

Why: Names and values are type-checked.

1. AonFocusOut
2. BonLeave
3. ConTouched
4. DonBlurCorrect answer

Why: Validation timing is configurable.

1. AisLoading
2. BisPosting
3. CisSubmittingCorrect answer
4. DisPending

Why: Read it via form.Subscribe.

1. ACSS
2. BThe server only
3. CForm-level validatorsCorrect answer
4. DEach field only

Why: They see all values.

1. Aaddress:city
2. Baddress.cityCorrect answer
3. Caddress->city
4. Daddress/city

Why: Dot and bracket paths.

1. AasyncDelay
2. BthrottleMs
3. ConChangeAsyncDebounceMsCorrect answer
4. Ddebounce: true

Why: It waits before calling the async validator.

1. AuseErrors()
2. Bfield.state.meta.errorsCorrect answer
3. Cform.errors[name]
4. Dfield.error

Why: Meta also holds isTouched and isValidating.

1. Aform.SubscribeCorrect answer
2. Bform.Watch
3. Cform.Observer
4. Dform.Consumer

Why: Only that subtree re-renders.

1. AInstall a required zod-adapter
2. BConvert it to JSON first
3. CIt is not supported
4. DPass it directly; Standard Schema is supportedCorrect answer

Why: Zod, Valibot and ArkType work as is.

1. Amode="array"Correct answer
2. Btype="array"
3. Carray={true}
4. Dmultiple

Why: It adds pushValue and removeValue.

1. Avalidators.onChange
2. BonBlur
3. Cwatch
4. Dlisteners.onChangeCorrect answer

Why: e.g. reset a dependent field.

1. AisTouched
2. BisValidatingCorrect answer
3. CisSubmitting
4. DisDirty

Why: Show a spinner.

1. AcreateSection
2. BFormPart
3. CwithFormCorrect answer
4. DuseFormSection

Why: From createFormHook.

1. AValidate on unmount
2. BValidate in CSS
3. CValidate the current step's fieldsCorrect answer
4. DSkip validation

Why: Then submit once.

1. AuseContext
2. BuseFormValue
3. CuseStore(form.store, selector)Correct answer
4. DuseForm only

Why: Fine-grained updates.

1. AlinkedFields
2. BonChangeListenToCorrect answer
3. CdependsOn
4. Dwatch

Why: Used for confirm-password checks.

1. AcreateField
2. BwithForm only
3. CuseFieldArray
4. DcreateFormHookCorrect answer

Why: It returns useAppForm.

1. AReact Context only
2. BMobX
3. CTanStack StoreCorrect answer
4. DRedux

Why: Fields subscribe to slices of the store.

1. Aform.reset()Correct answer
2. Bform.clear()
3. Cform.restore()
4. Dform.init()

Why: reset(values) can also set new defaults.

1. AThe user changed the fieldCorrect answer
2. BThe field has errors
3. CThe field is focused
4. DThe form submitted

Why: Show errors after touch.

1. AonMountCorrect answer
2. BonInit
3. ConLoad
4. DonRender

Why: For pre-filled data.

1. ASet field errors from the submit resultCorrect answer
2. Balert()
3. Cconsole.log
4. DReload the page

Why: Map messages to fields.

1. AMock the form
2. BType, blur and assert visible errorsCorrect answer
3. CRead internal state
4. DSnapshot the store

Why: Test what users see.

1. ANever
2. BWhile validators report errors or it is submittingCorrect answer
3. CAlways before submit
4. DOnly offline

Why: Disables the button.

1. Afield.pushValue only
2. Bform.reset
3. Cfield.clear
4. Dfield.handleChangeCorrect answer

Why: Or push and remove items.

1. AA new form library
2. BA server action
3. CA field component registered with createFormHookCorrect answer
4. DA CSS class

Why: Reusable and typed.

1. AisChecking
2. BisValidatingCorrect answer
3. CisPending
4. DisLoading

Why: It lives on field meta and form state.

1. ABackbone
2. BEmber
3. CLitCorrect answer
4. DjQuery

Why: Also React, Vue, Angular, Solid, Svelte.

1. AuseId
2. BuseActionStateCorrect answer
3. CuseEffect
4. DuseMemo

Why: Merges server state.

A reactive, client-side store for TanStack apps. Data loads into typed collections; live queries with filters, joins and aggregates update incrementally as the data changes; and optimistic mutations update the UI at once and sync to the backend, rolling back on failure. It aims at instant, local-first-feeling UIs while keeping your existing API.

Typed sets of objects that a live query reads from. A collection is created with createCollection and options that say where data comes from: a TanStack Query fetch (queryCollectionOptions), a sync engine such as ElectricSQL, localStorage, or local-only memory. Each collection also defines how inserts, updates and deletes are persisted.

useLiveQuery(q => q.from({ todo: todoCollection }).where(({ todo }) => eq(todo.completed, false))) returns results that stay up to date. Under the hood a differential dataflow engine recomputes only what changed, so updating one row costs about the same as one row, not a full re-query, even with joins across collections.

Calling collection.insert, update or delete applies the change to local state immediately, so every live query reflects it. The collection's onInsert, onUpdate or onDelete handler then persists it to the server. When the server confirms and new data syncs back, the optimistic state is replaced; if the handler throws, the change rolls back.

Provide onInsert, onUpdate and onDelete functions that receive the transaction with its mutations and call your API. After they resolve, the collection waits for the synced data (for a query collection, by refetching) to replace the optimistic state.

A query collection fetches through TanStack Query and works with any REST or GraphQL API, refreshing by refetching. A sync collection (for example ElectricSQL) streams changes from the database in real time, giving instant updates across clients but needing a sync engine.

A query can join collections on a condition (eq(todo.listId, list.id)) and select combined fields; the engine maintains the join incrementally, so updating one row updates the joined results without recomputing everything.

Query fetches and caches server responses per key; DB normalises that data into collections you can query, join and mutate locally with fine-grained reactivity. A query-backed collection uses Query for fetching, so you can adopt DB gradually on top of existing endpoints.

When the UI needs to combine and filter lots of related client data quickly (dashboards, kanban boards, chat), when many components show different views of the same records, or when you want instant optimistic writes across all of them. For simple fetch-and-show pages, Query alone is enough.

A provider-agnostic TypeScript toolkit for AI features. It offers adapters for several model providers, streaming chat on the server, framework hooks such as useChat for the client, and type-safe tool definitions. It is in early (alpha) releases, so check stability before relying on it in production.

A tool definition declares a name, description and input schema (for example with Zod), giving typed arguments. The same definition can get a server implementation (database or API access) or a client implementation (UI actions), and tools can require user approval before running.

A server endpoint or Start server function calls the chat function with a provider adapter, messages and tools, and streams the response. On the client, useChat sends messages, receives the stream and exposes the message list, loading state and tool calls for rendering.

Use .where(({ todo }) => and(eq(todo.done, false), gt(todo.priority, 2))) with operator functions, .orderBy(({ todo }) => todo.createdAt, 'desc') and .limit(), all typed from the collection schema.

Collections accept a Standard Schema (Zod, Valibot, ArkType) to validate and type items, plus a getKey function returning each item's unique key.

Optimistic changes are layered over synced data. When server data arrives it becomes the source of truth; if the server rejected or changed something, the optimistic layer is dropped and the UI shows the server's version.

useLiveQuery returns data (and status) and re-renders when results change; dependencies can be passed so the query rebuilds when props such as a selected id change.

Use local-only or localStorage collection options for UI state such as drafts or preferences, so they participate in live queries and joins with server data while staying on the device.

Install the provider adapter, pass it with the model name to the chat call on the server, and keep the API key in server environment variables. Switching providers means changing the adapter and model, not the app.

You can switch or mix models (OpenAI, Anthropic, Gemini, local Ollama) by changing the adapter, not the app code, compare providers on cost and quality, and avoid lock-in. Type-safe per-model options still catch unsupported settings.

APIs may change between releases, documentation and community answers are thinner, and edge cases are less tested. Mitigate by isolating them behind your own modules, pinning versions, writing tests around the integration and keeping a fallback path.

Several mutations can be grouped into one transaction (for example with createOptimisticAction or createTransaction) so they apply optimistically together and persist with a single mutationFn. If it fails, all of them roll back.

Create a server route or server function that calls the AI chat function and returns its stream; on the client, useChat connects to that endpoint and renders tokens and tool calls as they arrive.

Mark the tool as needing approval; the model's tool call pauses, the UI shows the request, and execution continues only when the user approves, which suits payments or deletions.

A tool with a client implementation runs in the browser (for example updating UI state or reading local data); the result is sent back to the model to continue the conversation.

Create collections with local-only options or mocked handlers in tests, insert fixture data, render components using useLiveQuery, and assert UI updates after inserts and updates.

Authenticate users, rate-limit per user, cap message length and history, choose an appropriate model, set max output tokens, and log usage for monitoring.

Instead of re-running a query on every change, the engine updates the result with only the changed rows, keeping updates fast (often well under a millisecond) even with large collections.

A transaction groups optimistic changes and one mutationFn that persists them; until it resolves, live queries show the optimistic state, and on failure everything in it rolls back together.

Both are headless and framework-agnostic with adapters, type-safe by inference and composable: DB builds on Query and Store, AI pairs with Start server functions for secure model calls, and neither dictates your UI.

In the official TanStack docs and release notes, since both are young and their APIs and stability levels change between releases.

1. AOnly on the server
2. BOnly on page reload
3. CIncrementally as collection data changesCorrect answer
4. DEvery hour

Why: A differential dataflow engine recomputes only changes.

1. AuseQuery
2. BuseCollection
3. CuseDB
4. DuseLiveQueryCorrect answer

Why: It returns reactive results.

1. AThe app crashes
2. BThe change stays forever
3. CNothing is shown
4. DThe optimistic change rolls backCorrect answer

Why: Local state returns to the server truth.

1. AA page reload
2. BlocalStorage
3. CThe synced server dataCorrect answer
4. DNothing; it stays forever

Why: Server data is the truth.

1. AA local-only collection
2. BA static collection
3. CA sync collection such as ElectricSQLCorrect answer
4. DA query collection

Why: Needs a sync engine.

1. AA URL parameter
2. BServer environment variablesCorrect answer
3. CThe client bundle
4. DlocalStorage

Why: Call providers from the server.

1. AcreateCollectionCorrect answer
2. BdefineTable
3. Cnew Collection
4. DuseStore

Why: Options set the data source and persistence.

1. AfromQuery
2. BsyncWithQuery
3. CqueryCollectionOptionsCorrect answer
4. DuseQueryCollection

Why: Query fetches; DB holds and queries the data.

1. AFalse, only one collection per query
2. BOnly on the server
3. COnly with SQL strings
4. DTrueCorrect answer

Why: Joins and aggregates are supported.

1. AA model provider
2. BA provider-agnostic toolkit for AI featuresCorrect answer
3. CA GPU runtime
4. DA chatbot product

Why: It connects to many providers through adapters.

1. AuseAI
2. BuseCompletion only
3. CuseStream
4. DuseChatCorrect answer

Why: It manages messages and streaming.

1. AkeyFn
2. BprimaryKey
3. CgetKeyCorrect answer
4. DgetId

Why: Required on collections.

1. AA Standard Schema like ZodCorrect answer
2. BPropTypes
3. CJSON Schema only
4. DTypeScript alone

Why: Types and runtime checks.

1. Aequals
2. Bis
3. C==
4. DeqCorrect answer

Why: Plus and, or, gt and more.

1. AA local-only or localStorage collectionCorrect answer
2. BA sync collection
3. CA query collection
4. DA server function

Why: Stays on the device.

1. AWaits for the user before runningCorrect answer
2. BRuns twice
3. CSkips the model
4. DRuns on the GPU

Why: For risky actions.

1. AOn the server or the clientCorrect answer
2. BOnly on the server
3. COnly in the browser
4. DOnly in the model

Why: One definition, either implementation.

1. AA JSON file on disk
2. BAn input schema such as ZodCorrect answer
3. CA SQL table
4. DA CSS class

Why: Arguments are typed from the schema.

1. AA transactionCorrect answer
2. BA selector
3. CA query key
4. DA loader

Why: They apply and persist as one unit.

1. AJest
2. BNginx
3. CElectricSQLCorrect answer
4. DWebpack

Why: Collections can sync from Postgres via Electric.

1. AJoins
2. BRe-running whole queries on every changeCorrect answer
3. CUsing indexes
4. DCaching

Why: Updates only changed rows.

1. AIn CI
2. BIn the browserCorrect answer
3. COn the model provider
4. DIn the database

Why: Results go back to the model.

1. AAuth and per-user rate limitsCorrect answer
2. BLarger models
3. CNo logging
4. DLonger prompts

Why: Also cap tokens.

1. AOnly the first rolls back
2. BNothing
3. CIt retries forever
4. DAll its optimistic changes roll backCorrect answer

Why: All or nothing.

1. AsortBy
2. Border
3. Csort
4. DorderByCorrect answer

Why: Typed from the schema.

1. AChange the database
2. BChange the router
3. CChange the adapter and modelCorrect answer
4. DRewrite the app

Why: Provider-agnostic design.

1. AOnly in production
2. BBy mocking React
3. CIt cannot be tested
4. DLocal-only collections with fixture dataCorrect answer

Why: Assert UI updates.

1. ALong-term support
2. BDeprecated
3. CEnterprise only
4. DEarly (alpha)Correct answer

Why: Check stability before production use.

1. AOfficial docs and release notesCorrect answer
2. BOld blog posts
3. CGuesswork
4. DSocial media only

Why: Both change quickly.

1. AData and status that update reactivelyCorrect answer
2. BA promise only
3. CA SQL string
4. DA collection

Why: Re-renders on change.