framework
framework copied to clipboard
feat: `useNuxtData` composable
🔗 Linked issue
resolves #9260
❓ Type of change
- [ ] 📖 Documentation (updates to the documentation or readme)
- [ ] 🐞 Bug fix (a non-breaking change that fixes an issue)
- [ ] 👌 Enhancement (improving an existing functionality like performance)
- [x] ✨ New feature (a non-breaking change that adds functionality)
- [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to change)
📚 Description
It introduces a new useNuxtData
composable.
📝 Checklist
- [x] I have linked an issue or discussion.
- [x] I have updated the documentation accordingly.
Open in CodeSandbox Web Editor | VS Code | VS Code Insiders
I really like this idea of optimistic UI.
I would personally rename it to getNuxtData()
.
Happy to get feedback also from other team member
Related PR to access data: nuxt/framework#7569
I think useNuxtData
makes sense (comparing to useData()
in other PR and getNuxtData()
). We use use*
prefix for composables that use implicit context/CAPI. And also nuxt
in the name makes sense.
Comparing to nuxt/framework#7569:
- We could support
key
param to get one data - We should return a ref IMO to allow changing value by key
Thanks for looking into this! I've updated the PR base on @pi0's suggestion
Thanks again dear @mahdiboomeri <3 A short explainer of recent changes:
-
useNuxtData
requires an explicit key. This makes usage easier and also explicit for keys (excluding auto generated keys). Also allows more flexibility to change the implementation in the future. - Return value of
useNuxtData
is{ data: Ref }
. This makes it consistent with other data composables and also ensures to have upward compatibility to add any other fields related to data - Docs updated as daniel suggested to cache value of
useNuxtData()
outside of handler. However we restore context and it is always available on client-side, it cannot always work in async conditions where nuxt context is lost. It also makes examples easier to read as we call it once.