[Feature request] Allow throwing an error in key getter function

[matthew-dean]

So, my actual use case is this:

I want to do client-side validation, and I have a general wrapper for useSWRV that passes back refs for data, error, etc. For some query parameters, I want to do client-side validation, and if it errors, I want to assign that to the error ref.

My first thought was: "Oh, maybe I can just throw an error in the key getter." However, that didn't work, as there's no error handling there. I thought maybe I could dynamically pass it to the fetcher function, but I don't see how without messing up hashing of the key. In other words: the query object is reactive, and will trigger a mutate automatically, so this validation has to happen "within" the useSWRV callback somehow.

IMO the easiest would be to allow errors to be thrown in the key getter, which then get assigned to error. Unless there's some other method you can think of?

[adamdehaven]

For some query parameters, I want to do client-side validation, and if it errors, I want to assign that to the error ref.

Does this mean you're wanting to validate the query parameters match a certain format, etc.? If that's the case, wouldn't it be done before the call to swrv?

I'd need to see a reproduction or something to fully understand what you're wanting to do, but as I understand what you're suggesting I don't believe throwing an error in the key getter is ideal.

[matthew-dean]

Does this mean you're wanting to validate the query parameters match a certain format, etc.? If that's the case, wouldn't it be done before the call to swrv?

TL;DR -- Okay I was able to fix this by throwing an error in the fetcher function itself. I still wanted to hook earlier than reactively assembling a new URL / key, but it works.

---

What I wrote earlier....

---

Well, think of it this way. swrv is designed to be reactive. In a normal use case, I'm assigning parameters to the useSWRV call. After that, I'm not "calling" it at all. I'm simply changing values and then useSWRV is fetching. But there's no way I can see to "intercept" the reactive fetch call.

In addition, I don't want to track multiple "error" refs that represent an error with the same data.

So, say I have this abstraction:

const {
  data: vanityCodeData,
  loading: vanityCodeLoading,
  error: vanityCodeError
} = useClient(
  () => vanityCode() && '/api/v1/reports/shorturl/check-vanity-availability',
  {
    query: {
      domain: selectedDomain(),
      vanityCode: vanityCode()
    }
  }
)

useClient is just an abstraction over useSWRV that sets convenient refs like loading. And query is just appending query parameters to the URL. So if vanityCode changes (it tracks a Vue ref), useSWRV will fetch. Now, I recognize I could abstract another ref on top of vanityCode, and I could additionally externally track another error ref and then combine the error refs. I can do all those things, but it's very verbose for each use case where I want to validate before fetching. All I want to do here is be able to register a pre-fetch hook with useSWRV, similar to hooks in something as ancient as jQuery's AJAX methods. Because useSWRV is instantly reactive, and each key recalculation causes a fetch, there is no opportunity to stop the fetch and do something else.

Maybe the key getter is not the right place...

Okay, I got it to work by passing a Zod schema to my abstraction, then throwing an error in the fetcher function if it doesn't pass validation.