how to handle non array api responses

[tigawanna]

Hey guy , am really loving this liband the flexibility it's unlocking

I have a question on when the api returns an object with pageOptions like page and totalPage and items as the array of data
currently am having to just rerturn the data.items from the collectionqueryoptions

export const communityWatchlistCollection = ({
  keyword,
  page = 1,
}: CommunityWatchlistCollectionProps) => {
  return createCollection(
    queryCollectionOptions({
      queryKey: ["watchlist", "community", keyword, page],
      queryFn: async () => {
        const response = await pb.from("watchlist").getList(page, 50, {
          filter: and(
            or(like("title", `%${keyword ?? ""}%`),
             like("overview", `%${keyword ?? ""}%`),
              like("user_id.username", `%${keyword ?? ""}%`)
            ),
            eq("visibility", "public")
          ),
          sort: "-created",
          select: {
            expand: {
              user_id: true,
              items: true,
            },
          },
        });
        return response.items;
      },
      queryClient: queryClient,
      getKey: (item) => item.id,
      schema: WatchlistResponseSchema,
    })
  );
};

i was wondering is there was a way to let the queryoption cache the whole object and pass a partial (data.items) into the collectionQurryotions and be able to create a local query collection with the page options since i don't care about optimistically updating them , hey're just metadta to know what pagination controls to render

the regular query options have a select field for shaping data while keeping the whole object cached wish we hav=de something similar here

export const communityWatchlistqueryoptions = ({
  keyword,
  page = 1,
}: CommunityWatchlistCollectionProps) => {
return queryOptions({
  queryKey: ["watchlist", "community", keyword, page],
  queryFn: async () => {
    const response = await pb.from("watchlist").getList(page, 50, {
      filter: and(
        or(
          like("title", `%${keyword ?? ""}%`),
          like("overview", `%${keyword ?? ""}%`),
          like("user_id.username", `%${keyword ?? ""}%`)
        ),
        eq("visibility", "public")
      ),
      sort: "-created",
      select: {
        expand: {
          user_id: true,
          items: true,
        },
      },
    });
    return response
  },
  select(data) {
    return data.items;
  },
});

kindly advice

[KyleAMathews]

👋 Thanks for the questions!

On returning arrays — this is necessary as DB has tighter data requirements than Query. A query cache can have anything while a collection is an array of typed objects.

On storing other metadata. Perhaps just manually write it to the query cache? We could perhaps support the select API as well — how does Query normally store the whole response? It's on a different key than the selected response? I'm sure we could do the same thing then.

[tigawanna]

If am not wrong the thing you return in your query function is what gets cached and select allows you to grab a partial of the query cache though it might also complicate writing back to the cache if some items could be arrays and other arrays in objects

In this case a select that allows you to point to where the main data array is in an object while allowing you to pass the rest in as metadata would be nice

In my case since am in expo i think i can even get away with sticking the metadata into zustand or manually putting it into the query cache