Why it needs to consider whether update fetcher dynamically or not..
Firstly, has a look at the basic usage of xswr
xs(path, customizedFetcher, options)
path
is used as an unique identifier to shared fetch pipe. According to data fetch optimization strategy , if path
value is equal, they will be considered as the same request.
However, maybe there is a situation, You may think whether fetcher should be updated dynamically.
xs('init', () => axios.post('/user', {
firstName: 'Fred',
lastName: 'Flintstone'
})).then(res1 => {})
xs('init', () => axios.post('/user', {
firstName: 'Charlie',
lastName: 'Flintstone'
})).then(res2 => {})
res1
and res2
will be resolved with same value even if firstName
is not the same in request body...
So how to fix this issue..
request should be token into account when creating path
const body1 = {
firstName: 'Fred',
lastName: 'Flintstone'
}
const p1 = `init_${JSON.stringify(body1)}`
xs(p1, () => axios.post('/user', body1)).then(res1 => {})
const body2 = {
firstName: 'Charlie',
lastName: 'Flintstone'
}
const p2 = `init_${JSON.stringify(body2)}`
xs(p2, () => axios.post('/user', body2)).then(res2 => {})
This solution will lost the cache benefit from xswr, because each request will a new Fetcher
, in-memory cache data will be a new empty object..
So, you will consider whether it will be better update an existing fetcher.
updating an existing fetcher
In order to support this solution, there need much source code change.
- Add a
update
method to fetcher
- In
update
method, fetch
, fetchArgs
and finalized
should be reset...
These two steps looks cover this issue. Now look the following example...
xs( "/api/user", url => service(url), {forceValidate: true}).then(r1 =>
xs( "/api/user", url => service("/api/update"), { forceValidate: true }).then(r2 => {
r1Counter++
if (r1Counter === 1) {} // r2 should be { name: 'liu' }
if (r1Counter === 2) {} // r2 should be { name: 'updated' }
xs( "/api/user", url => service(url), {forceValidate: true}).then(r3 => {
r2Counter++
if (r2Counter === 1) {} // r3 should be { name: 'liu' }
if (r2Counter === 2) {} // r3 should be { name: 'updated' }
if (r2Counter === 3) {} // r3 should be { name: 'liu' }. Actually, it is { name: 'updated' }
})
})
)
Re-think the reason why r3's value is {name: 'update'}..
Because, even thought fetch
, fetchArgs
and finalized
have been reseted. subscribers
is still be shared. when the old request resolved, it will execute all the subscribers.
Maybe you will think, so we just reset subscribers
... But in xswr
's design philosophy, fetcher is shared between application... because you do not know whether current path
fetcher is used by others', reset subscribers may cause other application lost its subscription...