How to Serialize Query Args??? Bug?

[rwilliams3088]

I would like to be able to supply things like Date objects as parameters to my endpoints (vs requiring the user to serialize things beforehand, which is tedious and susceptible to error).

So, for instance, I may have an endpoint like so:

export interface GetScheduleVariables {
  schedule: ScheduleIdentifier;
}

export const MyApi = createApi({
  reducerPath: 'myApi',
  baseQuery: fetchBaseQuery({ baseUrl }), 
  endpoints: (builder) => ({
    getSchedule: builder.query<GetSchedule, GetScheduleVariables>({
      // attempt to make RTK Query happy about the date...
      serializeQueryArgs: (params) => {
        return JSON.stringify({
          schedule: {
            code: params.queryArgs.schedule.code,
            date: params.queryArgs.schedule.date.toISOString()
          }
        });
      },
      query: (params) => ({
        ...
      })
    }),
  })
});

The request itself executes fine - but the console is filled with errors like this:

    A non-serializable value was detected in the state, in the path: myApi.queries.{"schedule":{"code":"5ea5d2ec-59f6-4ed1-a9d2-fed92e532c73","date":"2023-07-27T00:00:00.000Z"},"filter":{}}.originalArgs.schedule.date. Value: Date Wed Jul 26 2023 17:00:00 GMT-0700 (Pacific Daylight Time)

    Take a look at the reducer(s) handling this action type: myApi/executeQuery/pending.

    (See https://redux.js.org/faq/organizing-state#can-i-put-functions-promises-or-other-non-serializable-items-in-my-store-state)

So, despite the SerializeQueryArgs configuration, the Date object is hitting the store... Have I implemented my SerializeQueryArgs function incorrectly? Or is there something else I can try to serialize the arguments as part of my endpoint configuration?

[EskiMojo14]

serializeQueryArgs is used to turn the arguments into the string cache key, the original arguments are still saved to the cache entry in store. I don't believe there's a way to modify the arguments before they're saved to originalArgs.

[phryneas]

No, they are required in their original form if you ever want to call refetch.

[rwilliams3088]

Ok, I see that serializeQueryArgs is inappropriate for what I want to do - but then it seems like we are missing some basic functionality. I'd like users of my api to be able to call MyApi.useGetSchedules({ ... date: dtInstance }) rather than requiring that me/others serialize any complex objects themselves each time they want to invoke the api endpoints.

It seems like what we need is the ability to configure the use[Endpoint] and use[LazyEndpoint] to be able to serialize the data prior to going into the store, and perhaps a deserialization funciton to deserialize it whenever taken from the store.

As a workaround, I have silenced the serializableCheck for my API paths - but this seems hacky and indicative of missing functionality.

[phryneas]

It's pretty much impossible otherwise - see my last comment: how would you rerun the endpoints query function if you don't have the original input to it available any more?

[rwilliams3088]

@phryneas What I envision is fairly straight forward: You provide an optional serializer S and deserializer D to the endpoint configuration. When someone invokes use[Lazy]GetXXX(args) then, before those args get placed into the store, you simply call S(args) and send that to redux instead of args.

Then, internally, whenever RTK Query retrieves the serialized arguments sargs from redux and is about to use them - first call D(sargs) to deserialize them back into a complex object like a Date and proceed as normal.

This approach wouldn't maintain object references and thus re-runs should work.

I just want to make the API more convenient to use by shallowly including the (de)serialization that needs to happen. It seems to only be a question of whether the person invoking the API does it before they call the API, or of pushing the (de)serialization one level deep into the API.

That said, I'm no expert on the architecture behind redux and RTK Query - so let me know if there's some complication that would prevent such an approach from working.

I would also note that nearly half of the desired functionality is already present. Namely: you can handle deserialization via the selectFromResults option. The only thing missing here is the ability to define a defaultSelectFromResults on the endpoint vs requiring that it be supplied on each individual hook.

[markerikson]

Hmm. I'm open to ideas and suggestions for improving serialization / query args behavior in general, although this is probably low priority atm.

I will note that the serializable check middleware currently defaults to:

      ignoredActions = [],
      ignoredActionPaths = ['meta.arg', 'meta.baseQueryMeta'],
      ignoredPaths = [],

so we're already trying to ignore thunk args in actions. We could add a regex to ignore \.originalArgs$ or something like that too.

[rwilliams3088]

Hmm. I'm open to ideas and suggestions for improving serialization / query args behavior in general, although this is probably low priority atm.

I will note that the serializable check middleware currently defaults to:

      ignoredActions = [],
      ignoredActionPaths = ['meta.arg', 'meta.baseQueryMeta'],
      ignoredPaths = [],

so we're already trying to ignore thunk args in actions. We could add a regex to ignore \.originalArgs$ or something like that too.

Yes, perhaps simply defaulting the settings to allow for complex objects to be passed in as arguments to RTKQ queries and mutations out-of-the-box would be sufficient as a first step. At least then the hacky-ness would be encapsulated in the package. Here is what I came up with for my own store configuration for the time being:

const apis = [ /* api slices here */ ];

const serializableCheck:SerializableStateInvariantMiddlewareOptions = {
  // ignored paths within the application state
  ignoredPaths: apis.map(_ => _.reducerPath),

  // ignore these field paths in all actions
  ignoredActionPaths: ["payload", "meta"]
};

export const store = configureStore({
  reducer: apis.reduce((result, curr) => 
    Object.assign(result, { [curr.reducerPath]: curr.reducer }), {}
  ),
  middleware: (getDefaultMiddleware) =>
    apis.reduce<MiddlewareArray<any>>((result, curr) => 
      result.concat(curr.middleware), getDefaultMiddleware({ serializableCheck }))
      .concat(rtkQueryErrorLogger),
});

NOTE: I need to ignore complex objects in the above action paths since I automatically de-serialize the responses via transformResponse, and some of the deserialized data are complex objects. Albeit, at the moment the only complex objects are dates.

[phryneas]

Sidenote: Are you sure you really have a need for multiple apis? Are these really independent, unrelated data sources? Most apps should only ever have one api slice.

Your current solution there removes a lot of important type info from the store - you won't be able to e.g. dispatch thunks anymore.

[rwilliams3088]

Sidenote: Are you sure you really have a need for multiple apis? Are these really independent, unrelated data sources? Most apps should only ever have one api slice.

Currently I only have one Api (with endpoints broken out into multiple files, one per rails controller), but I may need hit the apis of multiple servers in the future (lots of microservices in our architecture).

Your current solution there removes a lot of important type info from the store - you won't be able to e.g. dispatch thunks anymore.

Currently my only use case for redux is RTK Query, and I have not yet found a need to mess with the thunks directly. Most of our state is managed via useState and other such React hooks. That said, I definitely agree that this configuration is not ideal - I just don't see a better option available at the moment to provide a clean interface to my endpoints that need complex objects. Hence the thread :)

[EskiMojo14]

instead of a reduce, try:
getDefaultMiddleware({ serializableCheck }).concat(rtkQueryErrorLogger).concat(apis.map(api => api.middleware))

[rwilliams3088]

instead of a reduce, try: getDefaultMiddleware({ serializableCheck }).concat(rtkQueryErrorLogger).concat(apis.map(api => api.middleware))

I like it :)

[Grawl]

Just fixed it

import { stringify } from 'qs'

export const api = createApi({
  baseQuery: fetchBaseQuery({
    // ...
    paramsSerializer: stringify,
  }),
})