Run & review this pull request in StackBlitz Codeflow.

✅ Live Preview ready!

If there are going to be breaking changes in the useFetch's signature I think it would be also be good to at least consider returning a reactive object rather than individual refs.

My reasoning is because currently returned values are refs we cannot leverage discriminated unions. With a reactive object however because it is not wrapped with refs typescript can build discriminated unions around it's type.

I had a working wrapper around the current useFetch already that is properly typed to leverage the benefits of the change I will post the repo here (or in the issue that we decide to track this in if that were to happen) once I clean it up a bit more and if there is any interest.

Benefits:

Simplified type checks around useFetch because we can just check the status and be sure that data is also there (for clarification this is already the case just typescript is not aware of it)

Improved DX for the reasons listed above

Downsides:

We lose the ability to destructure the useFetch call due to reactivity breaking

Potentially and most importantly a rather tedious migration experience (both in terms of code and convention/habits) for people that were using the destructuring pattern extensively

These were the ones that were obvious to me at first glance I am sure that there are more implications around this kind of a change that I am not aware of.