Add a recipe about custom factories for specific needs

[NazariiShvets]

Precondition: docs

So, the key is a hash of the following data:
- SID of the Query
- params of the particular call of the Query
- current values of all external Stores that affect Query
To get short and unique key, we stringify all data, concatenate it and then hash it with SHA-1.

Usually we have a lots of queries which is tied to user session. Common usecases:

• active user organization (in cases where app have two-layer auth).
• current role(permissions) of user (backend can in runtime change it)

But there is no api to provide this knowledge for cache (it usually does not passed in params but backend takes it from session tokens)

[igorkamyshev]

I like the idea 💙

But how is it connected with keepFresh? I assume it is about cache?

[NazariiShvets]

I suggest it as keepFresh parameter bcs its what first come to my mind when I tried to connect my session info to keepFresh

Sure, its more about cache than about keepFresh. So if you think it better suited there I think it ok

[igorkamyshev]

keepFresh already can use implicit deps. Just put it in triggers field 😇 https://farfetched.pages.dev/api/operators/keep_fresh.html#keepfresh-query-config

So, what this new field should do to cache? I do not get it.

[NazariiShvets]

I think its important to account for this in cache key, bcs it could lead to unnessesary cache hits

Bcs when i switching my accounts, and see cached data from previous account it doesnt look right
But i still want cache for previous account to be present, and hit it when i switch account back

[igorkamyshev]

So, why you do not want to use smth like this:

sample({
  clock: switchAccount,
  target: purgeCache,
})

cache(query, {
  purge: purgeCache
})

https://farfetched.pages.dev/api/operators/cache.html#formulae

[NazariiShvets]

Sure u can purge it. And its the only way to deal with this kind of cases

My point is — add ability to preserve that cache than your depencenies changing instead of purging that data, and hit it when dependency changed back(if cache exist), so u dont need to load that data again if it still fresh

[igorkamyshev]

So, we talk about something like this?

cache(query, {
  extraDependencies: [$userStatus]
})

But I still do not understand, how this extra dep can influence the result of the Query if you do not pass it to the Query?

const query = createJsonQuery({
  request: {
    headers: combine($userStatus, ...)
  }
})

In this case, $userStatus would be used as dependency for cache key generation automatically.

[NazariiShvets]

So, we talk about something like this?

cache(query, {
  extraDependencies: [$userStatus]
})

Yes, something like that

But I still do not understand, how this extra dep can influence the result of the Query if you do not pass it to the Query?

const query = createJsonQuery({
  request: {
    headers: combine($userStatus, ...)
  }
})

In this case, $userStatus would be used as dependency for cache key generation automatically.

1. Its doesn't not work with createQuery
2. Not all the time its suitable to actually send that info. And bcs of that, extraDependencies is needed

Another aproach is to pass as parameters, wrapping effect with attach, and remove that meta info from actual call.
But it doesnt create a relation as sourced field. So this aproach is:

• far less convinient
• lacks features(side-effects) provided by sourced fields (keepFresh.automatically, connectQuery)

[NazariiShvets]

I spend some time digging codebase, and from that i could tell, i easier to add extraDependencies to createQuery itself, rather than making query.__.sourced reactive (and we need to make it reactive, so order of attaching cache, keepFresh doesnt matter)

Also it should be easy to propagate this param to createJsonQuery

So it seems that this issue should be renamed to ... option to createQuery 🙃

What u think about that?

[igorkamyshev]

I'll think about this case.

[igorkamyshev]

I believe, you can achieve this behavior with custom factory with passing your extraDepa to sourced of createHeadlessQuery.

Does it work for you?

[NazariiShvets]

Yes, this is implementation to which i come trying to bring this feature in

But it(createHeadlessQuery) too low-level to use as default factory for all queries. For my cases, where i can replace createQuery with createHeadlessQuery and duplicate code of createQuery inside my codebase it can be done. But if I would build my app using high-level abstractions like createJsonQuery it would be devastating to fallback all factories to createHeadlessQuery

[igorkamyshev]

So, just write createNazarQuery in your own code and use it everywhere. I see not reasons to bring it to the core.

[igorkamyshev]

I renamed this issue to reflect it ☺️ I'll write the recipe.