-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Export default SWR config to allow more flexible extensions #1023
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 169909c:
|
I feel it would be more convenient to change value of SWRConfig to support function, with defaultConfig as argument. to avoid config argument in callbacks been overridden. <SWRConfig
value={(defaultConfig) => {
return {
onErrorRetry(...args) {
// customization
defaultConfig.onErrorRetry(...args)
}
}
}}
>
<App />
</SWRConfig> Then you can customize the callbacks at the top root. |
Thanks for suggestion @huozhi, in normal application it makes sense. Our use case is bit different though. We are building our own reusable hook that wraps |
I see your point, current accessing IMO we can add property // use-swr.ts
const config = Object.assign(
{},
defaultConfig,
useContext(SWRConfigContext),
args.length > 2
? args[2]
: args.length === 2 && typeof args[1] === 'object'
? args[1]
: {}
+ { defaults: defaultConfig }
) then you're able to customize it through hook options like beblow. This can also keep the exposed API as minimal as possible. useSWR(key, fn, {
onErrorRetry(err, key, config) {
const defaultOnErrorRetry = config.defaults.onErrorRetry
// customization
}
}) |
-1 on |
Both options would work for us, so don't mind which one you decide to go with. Do you want me to go and update this PR that way or will you do it by your own? |
@jakubriedl go ahead with |
is this the way you expected @huozhi ? |
Thanks @jakubriedl! Will publish a pre-release soon. |
To allow more flexible customisations and extensions it would be useful to export default config.
Eg. in our case we want to extend
onErrorRetry
but keep the current logic. Now we had to copy-paste the default config to our wrapper instead of calling it.