fix(head): inject `<script>` in rendered HTML when `ssr: false`
🔗 Linked issue
#5492
❓ Type of change
- [ ] 📖 Documentation (updates to the documentation or readme)
- [x] 🐞 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
Add global Header to prerenderd HTML on spa mode. This is just a first draft, so I would welcome some feedback. For example how to better handle the creation of the meta object, as I have seen there are two libraries for generating the meta object.
Resolves #5492
📝 Checklist
- [x] I have linked an issue or discussion.
- [ ] I have updated the documentation accordingly.
Deploy Preview for nuxt3-docs canceled.
| Name | Link |
|---|---|
| Latest commit | fc0ee3fefe31069373bde990f7cf55cac2607b9d |
| Latest deploy log | https://app.netlify.com/sites/nuxt3-docs/deploys/62b22e8d2757790008eecdca |
Thank you for the PR, indeed this is a feature we are missing from Nuxt 2. I will let @pi0 and @danielroe check about the implementation details if there is not a better way than hooking into nitro:config.
Also something I would like to explore later if the ability to render an "App shell" or rendering app.vue to get the meta data defined in this component.
Thanks for the initial work on this PR @JulianMar. Indeed this is what we have to reintroduce for Nuxt 3 to have the ability to add rendered meta tags and probably more hooking to customize the shell.
But not adding them from the build context (module) and using a nitro plugin to inject (It works for ssr: false and spa pages as well) since we are moving all the rendering logic to the runtime (#5534) This way we can inject dynamic headers after build which was SUPER tricky for nuxt 2 implementations such as for PWA module making an exception for ssr: false (and impossible hybrid rendering)
Something else I would like to have alongside this new feature is to decouple head implementation from vue. We don't really need a vue instance to render head objects and this can help save bundle size (when moving to render logic to the runtime) and we are already thinking to do that. I think it worth waiting for it before moving forward with this feature :) (With nuxt/nuxt.js#14182, we can actually have a custom module making same effect of this PR in the meantime)
Thanks for the review! It would make sense to wait for the two hooks as they would make it way easier to add this functionality. It was kinda hard to find the "correct" way to do this right now and it didn't feel correct either.
You want to decouple the head implementation from vue. Does that mean you just want to remove the plugins and do most of it server side or just don't attach it to the nuxt instance? I am just curious about how this will work together, and I am not that deep in nuxt yet :D
I will keep an eye on the issue for any discussions and thanks again for your awesome work with nuxt 3!
You want to decouple the head implementation from vue. Does that mean you just want to remove the plugins and do most of it server side or just don't attach it to the nuxt instance? I am just curious about how this will work together, and I am not that deep in nuxt yet :D
The idea is to split @vueuse/head into a generic JS lib for head generation and vue bindings to the Nuxt core. This way we have a stable head API for nuxt using same logic of common lib that can power ideas such as this and upcoming @nuxt/script module. Probably more possibilities. Essentially any head logic that needs to live outside of (Vue)SSR lifecycle.
Hi @JulianMar. I've added a quick workaround here https://github.com/nuxt/nuxt.js/issues/14172. I've to close PR since is stalled but will do my best to deliver unjs util ASAP making it easier for integration. In the meantime, you can create it using a nitro plugin (please ping if need help on how)
And once again, thanks for contributing to Nuxt <3