🧵 Composing RTK Query Endpoints for Richer Queries: A Proposal

[fernandocamargo]

Hi Redux Toolkit team (and maintainers and community as whole)! 👋

We’ve been experimenting with a pattern that composes RTK Query endpoints from one another, and it’s proven to be powerful, expressive, and DRY. Before we fully commit to this architecture, we’d love your thoughts on whether there are any hidden pitfalls.

🎯 The Goal

We want to build richer queries by composing simpler ones, without losing the benefits of RTK Query like caching, async state tracking, invalidation, and a central source of truth.

Let’s say we already have endpoints like:

getUsers: builder.query<User[], void>({...})
getDepartments: builder.query<Department[], void>({...})

We want to build:

getUsersWithDepartments: builder.query<UserWithDepartment[], void>({...})

…but instead of duplicating logic or re-fetching data from the backend, we compose the result from getUsers and getDepartments.

✅ What This Looks Like

getUsersWithDepartments: builder.query<UserWithDepartment[], void>({
  async queryFn(_arg, { dispatch }) {
    try {
      const [users, departments] = await Promise.all([
        dispatch(api.endpoints.getUsers.initiate()).unwrap(),
        dispatch(api.endpoints.getDepartments.initiate()).unwrap(),
      ])

      const departmentMap = Object.fromEntries(departments.map(d => [d.id, d]))

      const enriched = users.map(user => ({
        ...user,
        department: departmentMap[user.departmentId],
      }))

      return { data: enriched }
    } catch (error) {
      return { error: { status: 'CUSTOM_ERROR', error } }
    }
  },
})

💡 Why We Like It

Here are some of the strongest advantages we’ve found.

---

1. No Duplication of Business Logic

• The backend doesn’t need a new endpoint.
• No duplication of the logic to merge users with departments — it lives in a single place.
• Perfect separation of concerns: fetch logic remains pure and declarative.

---

2. Keeps RTK Query as the Source of Truth

All data fetching continues to go through RTK Query. The composed endpoint still benefits from:

• ✅ Built-in caching
• 🔄 Invalidation logic
• 🧼 Cache lifecycle control (keepUnusedDataFor, etc.)
• 🌲 DevTools visibility
• 🧪 Testability (mocked via msw or similar)

It avoids the temptation to do one-off manual compositions in useEffect or slices, which fragments the data layer.

---

3. Reuses Cached Data

Composed endpoints call .initiate() on the base endpoints, meaning:

• If the data is already in the cache, no fetch is triggered.
• If it’s not, the base query handles fetching and caching.
• This results in composed queries that are lazy, cache-aware, and efficient.

---

4. Observability for Free

Because composed endpoints are still RTK Query endpoints, components using them get the full async state suite:

const { data, isLoading, isFetching, isError, refetch } = useGetUsersWithDepartmentsQuery()

This gives excellent visibility into the request lifecycle — no need to invent custom hooks for polling, loading states, etc.

---

5. Simple Invalidations Cascade Naturally

You can tag your base endpoints and compose endpoints can still benefit:

getUsers: builder.query<User[], void>({
  providesTags: ['Users'],
  ...
})

getUsersWithDepartments: builder.query<UserWithDepartment[], void>({
  async queryFn(_, { dispatch }) {
    const users = await dispatch(api.endpoints.getUsers.initiate()).unwrap()
    ...
  },
  providesTags: ['Users'], // inherits tags for invalidation
})

So any mutation that invalidates ['Users'] also refreshes getUsersWithDepartments.

---

6. Memory Efficiency via Shared References

One subtle but important benefit of this pattern is that composed endpoints reference the same data structures as their base endpoints, thanks to caching and the use of shared unwrap() results.

This means:

• getUsersWithDepartments doesn’t create deep copies of user or department objects.
• The enriched data structures use shared object references to what's already cached by getUsers and getDepartments.
• If another part of the app updates or invalidates getUsers, that change is reflected anywhere getUsersWithDepartments relied on the same underlying cache.

📉 Result: Lower memory usage, less GC pressure, and zero duplication across multiple queries.

You essentially get normalization behavior without needing a normalized cache — the composition itself enforces data reuse.

---

🙋 What We're Asking

This pattern feels idiomatic and has been working well for us in production.

We’d love to know from the RTK Query maintainers and community:

Are there any caveats or gotchas with composing endpoints like this?

• Are we misusing .initiate() in any way?
• Could this lead to subtle bugs in cache management or invalidation?
• Would this approach break SSR or React Native edge cases?
• Could future versions of RTK Query change behavior around .unwrap() or cache reuse that would make this brittle?

If this pattern is safe and idiomatic, maybe it’s worth promoting as a first-class technique — or even enabling in a more declarative way someday? 🤔

Thanks so much for your work — RTK Query is amazing and we’re big fans! 🙌