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

fix: allow returning of falsy values from useAsync #670

Merged
merged 1 commit into from
Aug 19, 2022

Conversation

mango-martin
Copy link
Contributor

@mango-martin mango-martin commented Aug 6, 2022

Related to #493

If a falsy value is returned from useAsync, the client will always run the request again.

You could completely allow falsy values by adding a hasRun ssrRef but I fear it would pollute the global space.

So, as a compromise, with this change you can avoid having the client re-run a request if you return any falsy value other than null (and void)

Edit:
I guess another solution would be to convert the default ref value to an object, something like { data: null, hasRun: false } and maintain the single ssrRef that's already generated currently. But I think the proposed change is simple enough and really has no downsides to current behavior afaik.

@mango-martin
Copy link
Contributor Author

mango-martin commented Aug 6, 2022

To give a bit more context.

This is useful for error handling, like this.

<template>
  <div>
    <ClientOnly>
      <DataComponent v-if="data" :data="data" />
      <p v-else>404</p>
    </ClientOnly>
  </div>
<template>

<script setup>
import { myFetch } from '~/utils'

const data = useAsync(async () => {
  try {
    const result = await myFetch.do()
    return result
  } catch {
    return false
  }
})
</script>

Currently this kind of code will always send requests on both server and client process. With the change it will only run once.

@danielroe
Copy link
Member

I think this is a good change. Any reason you closed it?

@mango-martin mango-martin reopened this Aug 19, 2022
@mango-martin
Copy link
Contributor Author

@danielroe
Not really, I just thought it's not being considered. Reopened 👍

@danielroe
Copy link
Member

Sorry! I know how frustrating it can be when a pr doesn't seem to be looked at. 🙏

@mango-martin
Copy link
Contributor Author

Sorry! I know how frustrating it can be when a pr doesn't seem to be looked at. 🙏

No worries. I know you're super busy with Nuxt 3 atm. ❤️

@danielroe danielroe merged commit f8d9128 into nuxt-community:main Aug 19, 2022
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

Successfully merging this pull request may close these issues.

None yet

2 participants