Closed SomaticIT closed 3 years ago
Thanks :) Hummm, the others options will be jealous :grin: . Can we generate dynamically a function for each option ? and next we can expose these functions from an "updater" object. what do you think ?
Hmmm... I'm not sure that all options need this reactivity.
Maybe a good way to handle all other cases would be to add a function named updateOptions
or mergeOptions
that will merge given options with existing ones.
eg:
function mergeOptions(options: UseQueryOptions<TQueryFnData, TError, TData>): void {
observer.setOptions({ ...observer.options, ...options })
}
What do you think?
Yes, cool... it seems ok for me 👍
Do you have a preference on naming?
maybe updateOptions :)
Hi @amen-souissi,
I added the updateOptions
features about 10 days ago.
Did you have time to review?
Is there something missing before merging?
I'm so sorry I haven't seen the changes :( ... merged and released 👍
There is absolutely no problem 😁 !
Thank you for merging and releasing this, I will update my stack.
Can this apply to, useQueries, as well?
In some situations, we need to enable or disable queries using svelte reactive statements.
We can do this using the
setOptions
method but it forces us to pass all options. It could be very useful to have asetEnabled
shortcut function which reuse existing options and only update theenabled
option.It allows this code:
to become
It makes the code more readable and understandable.
Do you agree?