Memoized select selector outside a functional component — Next.js SSR concern

[amscu-dev]

Memoized select selector outside a functional component — Next.js SSR concern

Inspired by @TkDodo this post by TkDodo which mentions memoizing selectors, I wanted to implement the pattern of declaring the select function outside of a functional component.

---

🧩 Scenario

Looking to implement the pattern mentioned in the post — the one with the select function declared outside of a functional component — but implementing this in a Next.js application, where even client components are server-side rendered on the first render, would be a little problematic since subsequent requests would return the same cache entry.

---

📄 Current implementation

The hook:

// Called only once no matter how many components use useSuspenseQuery
const selectPost = memoize((response: ApiResponse<Post>) => {
  return response.data;
});

export const useGetPostById = <TData = Post>(
  id: number,
  queryConfig?: Omit<
    UseSuspenseQueryOptions<ApiResponse<Post>, AppError, TData>,
    "queryKey" | "queryFn"
  >,
  optionalAxiosConfig?: Omit<OptionalConfig, "signal">,
) => {
  // select is called only when ApiResponse<Post> changes
  return useSuspenseQuery<ApiResponse<Post>, AppError, TData>({
    queryKey: postQueryKeys.byId(id),
    queryFn: ({ signal }) =>
      postsApi.getById(id, { signal, ...optionalAxiosConfig }),
    select: selectPost as (response: ApiResponse<Post>) => TData,
    ...queryConfig,
  });
};

The client component consuming the hook:

"use client";

import { useGetPostById } from "../services/post.hooks";

const Post = ({ id }: { id: number }) => {
  const { data } = useGetPostById(id);
  return (
    <ul>
      <li>ID: {data.id}</li>
      <li>Title: {data.title}</li>
      <li>User ID: {data.userId}</li>
      <li>Completed: {data.completed ? "Yes" : "No"}</li>
    </ul>
  );
};

export default Post;

---

❓ Problem

In a Next.js application, the module-level memoize instance is long-lived and shared across all incoming requests on the server. This means that cache entries from different users or requests could contaminate each other — which is the same cross-request state problem that TanStack Query solves for QueryClient by creating a new instance per request on the server.

---

💡 Potential fix

Mirroring the QueryClient pattern — creating a fresh instance on the server while reusing a singleton on the browser:

// Singleton on the browser (reused between re-renders)
let browserSelectPost: ((response: ApiResponse<Post>) => Post) | undefined =
  undefined;

function makeSelectPost() {
  return memoize((response: ApiResponse<Post>) => {
    return response.data;
  });
}

export function getSelectPost() {
  if (environmentManager.isServer()) {
    // On the server: new instance per request
    return makeSelectPost();
  } else {
    // On the browser: reuse the existing instance
    if (!browserSelectPost) {
      browserSelectPost = makeSelectPost();
    }
    return browserSelectPost;
  }
}

export const useGetPostById = <TData = Post>(
  id: number,
  queryConfig?: Omit<
    UseSuspenseQueryOptions<ApiResponse<Post>, AppError, TData>,
    "queryKey" | "queryFn"
  >,
  optionalAxiosConfig?: Omit<OptionalConfig, "signal">,
) => {
  // select is called only when ApiResponse<Post> changes
  return useSuspenseQuery<ApiResponse<Post>, AppError, TData>({
    queryKey: postQueryKeys.byId(id),
    queryFn: ({ signal }) =>
      postsApi.getById(id, { signal, ...optionalAxiosConfig }),
    select: getSelectPost() as (response: ApiResponse<Post>) => TData,
    ...queryConfig,
  });
};

---

Is this the right approach, or is there a more idiomatic way to handle memoized selectors in a Next.js SSR context?

[mubashirdawood]

The cross-request contamination concern is valid in principle, but worth examining whether it actually applies to your specific selector before reaching for the QueryClient-mirroring pattern.

Why your selector is likely safe as-is

Your selectPost is a pure, request-agnostic transform — it only depends on the shape of ApiResponse, not on any user identity or request-specific context. Two requests that receive the same ApiResponse should produce the same result. That's not contamination, that's just memoization working correctly.
The real SSR risk with module-level memoize is unbounded memory growth — the cache on a long-lived server process never gets cleared between requests — not data leaking between users.

The issue with your proposed fix

On the server branch, getSelectPost() returns a brand-new memoize instance on every render call. A fresh instance has an empty cache, so it can never hit — you've eliminated contamination but also eliminated memoization entirely on the server. It works, but it's doing nothing useful there.

The more idiomatic approach: useMemo inside the hook

export const useGetPostById = <TData = Post>(
  id: number,
  queryConfig?: ...,
  optionalAxiosConfig?: ...,
) => {
  const select = useMemo(
    () => memoize((response: ApiResponse<Post>) => response.data),
    []
  );

  return useSuspenseQuery<ApiResponse<Post>, AppError, TData>({
    queryKey: postQueryKeys.byId(id),
    queryFn: ({ signal }) =>
      postsApi.getById(id, { signal, ...optionalAxiosConfig }),
    select: select as (response: ApiResponse<Post>) => TData,
    ...queryConfig,
  });
};

This sidesteps the SSR concern entirely without any isServer() branching:

Server: each request instantiates the component fresh → useMemo creates a new memoize instance → no cross-request state, no memory leak
Client: the component instance persists across re-renders → useMemo with [] returns the same stable reference → TanStack Query's select optimization holds, no unnecessary recomputation

The useMemo dependency array [] is intentional and correct here — the selector's identity doesn't depend on any prop or state, so it should be stable for the full lifetime of the component instance, which is exactly the guarantee you want on the client.