Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useHttpsCallback should reject when the call fails #321

Open
KaidenR opened this issue Jan 9, 2024 · 0 comments
Open

useHttpsCallback should reject when the call fails #321

KaidenR opened this issue Jan 9, 2024 · 0 comments

Comments

@KaidenR
Copy link

KaidenR commented Jan 9, 2024

I'm not sure if this was the intended behavior, but useHttpsCallable's callCallable function returns a Promise<HttpsCallableResult<ResponseData> | undefined> which is being used to say "if the call succeeds return the expected ResponseData shape. But if it fails, STILL resolve the promise but with undefined.

I'd like to suggest that it should reject with the error if the call fails. That way your calling code can handle the err response the same way it handles the success data. Right now you have to write separate code that watches for changes to the hook's returned error object.

Specifically I'm trying to advance the user to the next page if the call succeeds, or call some logging and notification functionality if it fails. I'd like to be able to do this:

const [joinTeam, isJoiningTeam] = useHttpsCallable<Req, Res>(functions, 'jointeam')()

const handleSubmitClick = async () => {
  try {
    await joinTeam()
    navigate('/team-page')
  } catch (err) {
    logger.error('Error joining team', err)
    notificationContext.showErrorNotification({ title: 'Unable to join team', message: err.userFriendlyMessage })
  }
}

Since the promise returned by joinTeam currently doesn't ever reject, I can't handle the error this way.

It looks like all we'd have to do is to re-throw the error after updating the state here:

setError(err as Error);

I can look into submitting a PR but I'd like to get everyone's opinions on the change first since it's technically an API change.

Thanks for the great library!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant