Allow hook to not throw when Provider is missing

[ghost]

I'm updating the internals of a data-fetching library to use react-query. We'd like to make the update non-breaking initially, but react-query's error when a Provider can't be found is making that tricky to achieve (I won't go into the architectural details if that's ok).

Now I've been looking at using a try/catch around react-query's useQuery, which works, but breaks the rules of hooks. What I'm looking for is the option to use react-query, but for it to not throw when a provider is missing. A more graceful failure state that won't crash the app basically.

Is the useQuery hook decoupled enough from the Provider that it could just operate without caching if a Provider can't be found? Because if so, an opt-in mode that will not throw on a missing Provider would be a solution to the problem above.

Or alternatively, if that's not possible, a flag that when set will not throw the provider error, but return it under the error returned by the hook for example.

Would any of that be in scope for this project?

[TkDodo]

Not sure how this should work. The Provider provides the QueryClient, which contains the QueryCache with all the data and all the options

[ghost]

Yeah I see what you mean. And I guess that for that same reason, it would be tricky to deal with the error here: https://github.com/tannerlinsley/react-query/blob/69d88cca55915a1830d66465289ecc2a6e83329f/src/react/QueryClientProvider.tsx#L38 in another manner?

Do you see a way for react-query to support a failure mode for a missing provider that doesn't throw?

[TkDodo]

I'm no sure why you would need that. It's like trying to use redux without a ReduxProvider, that's not how it works.

This request looks a bit like an xy question to me - I don't know the reason why you think you need this behaviour :) Maybe if you could describe that, we could find a solution to the real problem without needing this at all

[ghost]

I'm no sure why you would need that. It's like trying to use redux without a ReduxProvider, that's not how it works.

Yeah I see what you mean. Yes I think it's probably best to describe the usecase: so the org. I'm implementing this for (@dhis2) has a data-fetching hook. For this data-fetching hook they want to enable caching, SWR, etc. The functionality that react-query provides basically.

So their custom data-fetching hook is already used throughout the ecosystem. The senior devs felt it best to not switch the entire ecosystem from that custom data-fetching hook to react-query, but to instead implement react-query under the hood for their own data-fetching hook. That way, they could try and require as little change as possible from the devs working in this ecosystem, and ideally the update would just require a feature bump.

So the changes have been implemented on an alpha branch here: dhis2/app-runtime#910.

One issue though, is that this change requires the react-query provider to be present (which makes sense of course). For the lib I'm changing, in the past the consumers didn't throw when a provider wasn't present. Whereas with the react-query provider it now will throw. So that is breaking change.

So ideally we'd be able to publish this as a feature bump. Now the core cause of this custom data-fetching hook breaking app-builds is because it needs another lib to be at least 7.1.1 or above to be able to always provide the react-query provider. Ideally we'd express this as a peerdependency (as that's the relation between the two packages), but it's not strictly always required. So that was the reason we were looking for alternative solutions.

However, in writing this I discovered that there's peerDependenciesMeta which resolves the above problem at the root. So I think that this feature request can be closed, as I think I've resolved the issue with the peerDependenciesMeta fix, and I agree that it doesn't really make a whole lot of sense from react-query's perspective to not throw on a missing provider. Hope that provides some context (😅), and thanks for the feedback!