Skip to content

refactor(nuxt): simplify request computation inside useFetch #26191

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

Merged
merged 4 commits into from
Mar 11, 2024

Conversation

Mini-ghost
Copy link
Member

πŸ”— Linked issue

N/A

❓ Type of change

  • πŸ“– Documentation (updates to the documentation, readme or JSdoc annotations)
  • 🐞 Bug fix (a non-breaking change that fixes an issue)
  • πŸ‘Œ Enhancement (improving an existing functionality like performance)
  • ✨ New feature (a non-breaking change that adds functionality)
  • 🧹 Chore (updates to the build process or auxiliary tools and libraries)
  • ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

πŸ“š Description

Currently, the implementation of _request inside useFetch is as follows:

const _request = computed(() => {
let r = request
if (typeof r === 'function') {
r = r()
}
return toValue(r)
})

This code is almost equivalent to toRef(request), should we just use toRef as a cleaner alternative?

I am open to feedback regarding whether this adjustment will yield significant benefits. Should the evaluation indicate that the drawbacks outweigh the benefits, please feel free to close this PR.

πŸ“ Checklist

  • I have linked an issue or discussion.
  • I have added tests (if possible).
  • I have updated the documentation accordingly.

Sorry, something went wrong.

Verified

This commit was signed with the committer’s verified signature.
danielroe Daniel Roe
Copy link

stackblitz bot commented Mar 11, 2024

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

Verified

This commit was signed with the committer’s verified signature.
danielroe Daniel Roe
@danielroe danielroe changed the title refactor: simplify request computation with toRef refactor(nuxt): simplify request computation with toRef Mar 11, 2024

Verified

This commit was signed with the committer’s verified signature.
danielroe Daniel Roe
@Mini-ghost
Copy link
Member Author

I'd like to understand if using a getter function as the parameter for request, especially when the calculations are very complex, could actually worsen performance. This is because every time _request is accessed, the getter function would be executed again .

Of course, for users passing in a type of Ref<ReqT> | ReqT, this should not pose a problem.

@danielroe
Copy link
Member

Does toRef re-execute the function every time .value is accessed?

@Mini-ghost
Copy link
Member Author

I attempted to write and execute the following code:

const text = toRef(() => {
  console.log('accessed test');
  return 'test';
});

console.log(text.value);
console.log(text.value);
console.log(text.value);

I accessed text.value three times, and it resulted in the following output:

accessed `text.value` three times

Therefore, using a getter indeed causes multiple executions.

@Mini-ghost
Copy link
Member Author

Mini-ghost commented Mar 11, 2024 β€’

As an adjustment, perhaps it could be modified like this:

 const _request = computed(() => toValue(request)) 

Or

const _request = typeof request === 'function' ? computed(request ) : toRef(request)  

@danielroe
Copy link
Member

I think computed(() => toValue(request)) looks best to me. Thank you for investigating.

@Mini-ghost Mini-ghost changed the title refactor(nuxt): simplify request computation with toRef refactor(nuxt): simplify request computation inside useFetch Mar 11, 2024
@Mini-ghost Mini-ghost requested a review from danielroe March 11, 2024 16:11
@danielroe danielroe merged commit 79cdb0b into nuxt:main Mar 11, 2024
35 checks passed
@github-actions github-actions bot mentioned this pull request Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants