Open tinaszheng opened 2 years ago
Hi @tinaszheng 👋🏻 thanks for opening this issue and for sharing your idea! My initial thoughts are that defining "sticky" errors and other composite statuses might be best done in userspace rather than making it a feature of the client, but that's not a strongly-held opinion and it would be great to hear different perspectives on this
Problem: Right now, we have a query with a polling interval, and we read
loading
,error
, anddata
from the return results. We then render different error and loading UIs based on the return values:The problem is since there is a polling interval combined with error handling,
error
becomesundefined
when the query is in a polling state, and result is that the UI flickers between the Error component and the Loading component.Solutions we could try:
error
and saves it in state until the next poll returnsusePersistedError
that does the same persistence of error state but outside of a custom hook wrapperHowever, we're using this pattern throughout our codebase so it's a little annoying to have to do this everywhere.
Suggested solution: Allow us to pass in a custom
QueryHookOption
:persistError
that we can set at the global level that basically persists any previously returned errors while the network status is either refetching or loading.Notes And of course if there's already an easy way to do this, lmk 😅