An example of using createEntityAdapter and RTK Query without using endpoints.endpoint.select

[JoeVanGundy]

I'm wondering if it's possible to add an example of using createEntityAdapter and RTK Query without using endpoints.endpoint.select?

I've been doing a POC with RTK Query in our app.
Everything's been great until I've tried using createEntityAdapter.

I've followed the advanced pattern docs, but no matter what, my selector return nothing.

The docs seem confusing on to properly handle this.
I just want to use the selectAll selector from the adapter so do I need to actually pass anything to usersAdapter.getSelectors()?
I saw in an StackOverflow post that I shouldn't even need to user endpoints.getUsers.select(null); right?

I can't find an example in the code of how to not use that, and I can't get to work when I have to use it.
I didn't see any typescript implementation of this, so it's possible one of my assumptions broke it.

Could it be that I'm not directly calling: store.dispatch(extendedApiSlice.endpoints.getUsers.initiate());? Instead I'm just using the hook? It's my understanding that I shouldn't need to do all these manuel steps right?

Here is my code. I've copied the code straight from the docs, and updated it to hit my endpoint (/dashboards/${dashboardId}/shares)

My Slice, the only thing different from the docs is my query path

const dashboardSharesAdapter = createEntityAdapter();

const initialState = dashboardSharesAdapter.getInitialState();

export const extendedApiSlice = apiSlice.injectEndpoints({
  endpoints: (builder) => ({
    getDashboardShares: builder.query({
      query: (dashboardId) => `/dashboards/${dashboardId}/shares`,
      transformResponse: (res: any) => {
        return dashboardSharesAdapter.setAll(initialState, res?.data);
      },
    }),
  }),
});

export const { useGetDashboardSharesQuery } = extendedApiSlice;

// Here I'm passing undefined because typescript won't let me pass nothing. 
export const selectDashboardSharesResult = extendedApiSlice.endpoints.getDashboardShares.select(undefined);

const selectDashboardSharesData = createSelector(selectDashboardSharesResult, (dashboardSharesResult) => {
  // this is empty
  console.log('hi ', dashboardSharesResult);
  return dashboardSharesResult.data;
});

export const { selectAll: selectAllDashboardShares } = usersAdapter.getSelectors(
  (state: any) => selectDashboardSharesData(state) ?? initialState
);

The main api

export const apiSlice = createApi({
  reducerPath: 'api',
  tagTypes: ['DashboardShares'],

  baseQuery: fetchBaseQuery({
    baseUrl,
    prepareHeaders: (headers, { getState }) => {
      const { userJWT } = getState().user;
      headers.set('Content-Type', 'application/json');
      headers.set('Authorization', `Bearer ${userJWT}`);
      return headers;
    },
  }),
  endpoints: (builder) => ({}),
});

The App. Data is correct, but dashboardShares is empty.

  const { dashboardId } = useParams<{ dashboardId: string }>();

  const { isLoading: isDashboardLoading, data } = useGetUsersQuery<{
    isLoading: boolean;
    data: any;
  }>(dashboardId);

  const dashboardShares = useSelector(selectAllDashboardShares);

[markerikson]

The point of someEndpoint.select(cacheArg) is that it creates a selector function that knows how to retrieve the exact data for that cache entry from the Redux store, and it does that by correctly serializing the cache key argument. So, that piece is important, because that's how you can retrieve the right cache entry, which then contains your data inside.

Looking at your code: my first suggestion would be to finish updating the naming so that it's no longer getUsers, just for clarity.

The second issue is that getUsers.select(undefined) creates a selector that will retrieve the cache entry for the cache key undefined... but your endpoint actually needs a cache key of dashboardId. So, you're making a new selector that will never find the right cache entry.

Next, as a sorta different issue: you shouldn't be supplying TypeScript generic args to useGetUsersQuery. All the TS types should be defined as part of the endpoint.

In general, what you probably need is to do this inside the component:

const selectAllDashboardShares = useMemo(() => {
  const selectDashboardCacheEntry = someApi.endpoints.getDashboardShares.select(dashboardId);
  const { selectAll } = dashboardAdapter.getSelectors();
  return createSelector(
    (state) => selectDashboardCacheEntry(state)?.data,
    (cacheData) => {
      return cacheData ? selectAll(cacheData) ?? initialState
    }
  )
}, [dashboardId])

In other words:

• Make a customized selector that knows how to fetch this dashboard's cache entry
• Use that as the input to grab the data field (with the normalized entity state) out of the cache entry
• if that is real data, turn it into an array

[JoeVanGundy]

Hey @markerikson, really appreciate the feedback!

Totally right for readability, updated the code to use the actual names instead of placeholders.

Everything else you said totally makes sense, but I'm just wondering if I'm going about this the right way?
I really like entityAdapter because it solves having to write repetitive selectors for simple endpoints.
It sounds like if I use RTK Query, I've going to have to write that big selector example that you gave in every single component that needs the selectAllDashboardShares?

So hypothetically, if I have 10 components that use selectAllDashboardShares I would need to have that memoized selector defined in each of the components. Then if every of those 10 components needs a selectDashboardShareById call, I would need to memoize that as well?

That seems like a ton of of repeat/duplicate code? Am I going about that wrong, or is that just what you need to do to make RTK Query work?

Without RTK Query I would just have this in each of the component.

// MyComponent.tsx
const dashboardShares = useSelector(selectAllDashboardShares);
or
const dashboardShare = useSelector((state) => selectDashboardShareById(state, shareId))

...

// dashboardShareSlice.js
export const {
  selectById: selectDashboardShareById,
  selectIds: selectDashboardShareIds,
  selectEntities: selectDashboardShareEntities,
  selectAll: selectAllDashboardShares,
  selectTotal: selectTotalDashboardShares,
} = dashboardSharesAdapter.getSelectors<AppState>((state) => state.dashboardShares);

[phryneas]

What is your intent in combining these two? Are you aware that adding an entityAdapter will still keep all your cache entries separate from each other?

[JoeVanGundy]

Throughout my app I use the upsertOne/removeOne/etc quite a bit. I also use use the entityAdapter for local non-network redux actions and for the selectById/selectAll selectors.

Sounds like you might be saying RTK Query handles all of the same things entityAdapter does?
Is it a fair assumption that for standard apps, we can drop using entityAdapter for RTK Query?

What I liked about about entityAdapter is that it allow all components throughout my app to access the store in a standard way and it eliminates the need for the creation of repetitive selectors . For example, if a component wants to get a specific userPost by id from a getUserPosts call, then what would be my approach?

Would I just have to create all the selectors provided by createSelectors manually?
Or is there another way?

[phryneas]

They are just completely different concepts for completely different things.

For an entityAdapter, you have one central list of all the things you want to store somewhere - you create a normalized store, indexed by id.

With RTK Query, you just have a representation of endpoints. If you have a getPosts endpoint and a getPostById endpoint, maybe the post of id 23 is on the cache entries for getPosts({ page: 3 }) and also can be retrieved by calling getPostById(23). Those are independent of each other.
They might "accidentally" contain the same data, but for RTK Query it could just as well be apples and oranges - RTK Query does not care. All RTK Query does is give you a representation of "what do I get when I do a certain request to the server" and allow you to make those requests easily.
In your component, you will not try to select one specific id from a list of items, but you just call useGetPostByIdQuery(23). If that specific endpoint is in cache already, you get the cache value, if not it makes a request.
RTK Query does not really track what is in where or deduplicate things. It assumes the server always knows best and only provides you with tools to refetch data - for example if you edit the name of post 23, you probably want getPosts({ page: 3 }) and getPostById(23) both to be refetched from the server, so you have the current data for that again. For that, you would use invalidateTags.

[kriti-sc]

This was my mental model: vanilla Redux Store (I hope you understand what I mean by this) provides a common data layer for the application and RTK Query connects the data layer to the backend. So changes on the backend and local changes made on the app both flow to the Redux Store. The backend changes are pulled in using RTK Query and put into the Redux Store. The app uses selectors registered with the Redux Store, and changes in the state update the UI. Any changes made on the frontend flow to the Redux Store (again triggering rerenders across the app) and depending on user actions, are pushed to the backend using RTK Query.

As I look into RTK Query more and more, I realize this is not the case.

@phryneas what do think about my mental model?

[kriti-sc]

If I use createEntityAdapter with RTK Query, I am not able to use some RTK Query features such as granular invalidation and optimistic updates. Am I doing something wrong or is this to be expected?

[markerikson]

@kriti-sc : both of those comments seem confused.

RTK Query uses all the standard Redux patterns: thunks get dispatched, make async requests, dispatch actions with the results, and reducers handle caching the data and updating the status fields. Selectors in the UI run, check values, and re-render the UI. It's all the normal Redux data flow.

The difference is that with RTK Query, you didn't have to write any of that code yourself - RTKQ already did that work for you.

As for createEntityAdapter, you absolutely can use it with RTK Query - it's just that the normalization only applies to that one cache entry you've transformed:

• https://redux.js.org/tutorials/essentials/part-8-rtk-query-advanced#transforming-responses