Possible to support object keys?

[davecoates]

Would it be possible to support objects as keys rather than forcing everything to be a string?

In my case I'm looking to do something like

const { data } = useSwr(userDetail.prepare({ id: 5 }));

which returns the same object given the same inputs. The object itself has a method on it that is called by the fetcher:

function fetcher(preparedAction) {
    return preparedAction.call();
}

As it is this doesn't work because the object returned is forced to a string here: https://github.com/zeit/swr/blob/master/src/use-swr.ts#L66

Given the cache is a Map using an object as a key works, eg. changing that line to the following appears to do what I want:

else if (!key || typeof key !== 'object') {
        // convert null to ''
        key = String(key || '');
}

Wrapping it in an array does also work:

const { data } = useSwr([userDetail.prepare({ id: 5 })]);

but the ergonomics aren't as good (especially given if you forget to wrap it in an array it just doesn't work - no errors).

Unfortunately other things assume it's a string as well - eg. CONCURRENT_PROMISES etc are just plain objects rather than a Map.

Is this something that you would be willing to extend the API to accomodate?

My alternative to make this work within the current API constraints would be to have prepare return a string that fetcher can look up into my own global cache... but I was thinking it would be nice to avoid this if swr already did that internally.

[Svish]

For simple cases, you could do something along the lines of what I did for Axios here: https://github.com/zeit/swr/tree/master/examples/axios

It basically just wraps useSWR in a new hook which uses JSON.stringify to create a key for the request object. Works fine so far here at least 🙂

[Svish]

If you need a typescript example: https://github.com/zeit/swr/tree/master/examples/axios-typescript

Although your case might be a bit simpler since that example also handles the initialData and axios response object to equal the API of useSWR

[shuding]

@davecoates I like the idea 👍

CONCURRENT_PROMISES etc are just plain objects rather than a Map.
I think we'll keep it as a plain object for now, because otherwise the keys (if you use an object as key) can't be garbage collected (string keys are fine for now).

However it's okay to wrap it with an array automatically internally:

useSwr(object) 
// equivalent to
useSwr([object])

Thanks @Svish for the JSON.stringify suggestion (it can be handy sometimes too).

[Svish]

If you wrap it in an array like that, just make sure it's actually the exact same object each time... i.e. that userDetail.prepare({ id: 5 }) doesn't return a new object each time, because if it does, it will fail the reference check and trigger a new fetch. At least pretty sure that's what will happen... make sure to check in your network log to make sure it doesn't go nuts with new requests for the same id...

[shuding]

@Svish Yeah. The ideal use case of object keys is not for "params". The ideal case should be:

const { data: user } = useSWR('/api/user', fetch)
const { data: userPhotos } = useSWR(['/api/photos', user], fetchUserPhoto)

Because SWR deep compares & caches the data (user in this example), if you're managing all the data dependencies with SWR, the issue you mentioned will never happen ;)

[Svish]

@quietshu Looks like you'd need a custom fetcher for every new data dependency type or something then? 🤔

const { data: user } = useSWR(['/api/user', userId], fetchUser)
const { data: userPhotos } = useSWR(['/api/photos', user], fetchUserPhoto)

const { data: post } = useSWR(['/api/post', postId], fetchPost)
const { data: comments } = useSWR(['/api/comments', post], fetchPostComments)

...

[shuding]

@Svish If you want to use objects as the arguments — yes. But you can hide them inside custom hooks:

const { data: user } = useUser(userId)
const { data: userPhotos } = useUserPhoto(user)

const { data: post } = usePost(postId)
const { data: comments } = usePostComments(post)

...

But under the hood, it will always be a URL + headers in the HTTP request. So no matter which pattern you want to use inside your components, I'd always suggest to transform and pass it as a string key (w/ options) to useSWR:

function useUserPhoto(user, fetcherOpts = null) {
  return useSWR(user ? ['/api/photos?uid=' + user.id, fetcherOpts] : null, fetcher)
}

In that case you don't need any custom fetcher.

[Svish]

@quietshu Don't think I like how that looks, hehe. Think I'll stick with my JSON.stringify for now. 😛

Anyways, hope @davecoates found the answer he needed! And I do agree it would be super handy if useSWR allowed to use objects as keys, although also not sure how that would work internally, so personally I'll just stick with my hack, and not complain. 🤷‍♂️😛

[shuding]

Yeah @Svish it's good to use what works the best in different cases 👍

What I was sharing is, this pattern makes great sense from the point of view of the app structure too. In complex web applications, you definitely don't want to put the APIs and fetch handlers inside every single component that uses the data. Instead you can have a /data directory with all your data sources and use them like the example above.

And that works really well for us in the past 6 months. I'll share more details in the future with a concrete example.

[Svish]

Yeah, that's pretty much what we do now, except we have an api folder with files that generates Axios request objects. Basically like this:

// src/api/foobar/index.ts
import { ApiRequest, ApiRequestDetails } from 'api';
import config from 'config';

export const foobarRequest = <Data>(
  request: ApiRequestDetails<Data>
): ApiRequest<Data> => ({
  baseURL: config('foobarBaseUrl'),
  withCredentials: true,
  ...request,
});

// src/api/foobar/user/search
import { foobarRequest } from 'api/foobar';
import { GetRequest } from 'util/useRequest';
import { User } from '.';

export type SearchResult = User;

export const getSearchRequest = (term: string): GetRequest<SearchResult[]> =>
  term
    ? foobarRequest({
        url: '/api/user/search',
        params: { term },
      })
    : null;

The Api types are just subsets of the Axios request and response types.

[Svish]

Used in search component like this:

  const { data: searchResult, isValidating } = useRequest(getSearchRequest(term));

The useRequest hook is more or less what I added in the axios-typescript example, except it uses a subset of Axios types, rather than the full ones.

[o-alexandrov]

@quietshu
cc @Svish
Please let us know, if you would accept to include the:

• useRequest
  as a built-in method of the useSWR API?

The major issue with it being an example is all of the developers, who use axios with swr and that should be the majority of those who fetch RESTful API, are all duplicating the same concept and maintain it separately from the community.
It would be better, if you would accept a refactored built-in method, that would:

• allow to initialize the hook with global settings for both axios and swr, we could name it
  • setUseSWRAxios
    • the initializer would return a named function (hook) useSWRAxios
      • personally, I'm against of naming useRequest, as the naming pattern above allows us to add other modified useSWR hooks for other libraries useSWRAnotherLib
• minimize the memory footprint, by not duplicating data in data, and response returned keys

EDIT:
As a side note, it seems @quietshu already started to name the hooks that are modifiers of useSWR as useSWRSuspense. Therefore, the naming pattern started to defer in the examples and the to-be-added API:

• [RFC] useSWRSuspense (or Suspense guards) #168

[Svish]

I suppose? Want me to try put together a PR?