-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Conversation
|
β Deploy Preview for nuxt3-docs canceled.
|
@@ -29,70 +29,3 @@ export type AppHeadMetaObject = MetaObjectRaw & { | |||
*/ | |||
viewport?: string | |||
} | |||
|
|||
export interface MetaObject { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't figure out why this needed to be exposed by @nuxt/schema
exactly. The reactive object is only passed used as an argument for the useHead
function, nuxt.config.ts
uses the non-reactive schema.
The nuxt app itself exposes it as well. If we remove it then we don't need to depend on import the full module for the types
Will need to revisit this tomorrow. Tests are looking good still but issues with this CI and getting a module up for a playground |
I figured that having a proper v1 of @vueuse/head would help move this PR along, so it's now released. The first draft of documentation for https://unhead.harlanzw.com/ is complete. What's remaining is for me to spin up a playground and do some final nuxt-specific testing with edge cases, I hope to have that done by this time tomorrow. Aim to have it in a RC if the code is good |
Looks like I goofed up with the v1 release, didn't realise the constraint would jump from rc to 1.0.0. So in fact the nuxt core is now using v1 @vueuse/head for any new installs. I updated it to be fully backwards compatible to unblock any users, so this PR will now just be switching over from the deprecated functions |
@harlan-zw Will you release a v2 shortly then removing backwards compat? |
Nope, seems a backwards compat build for v3 stable is ideal, there are some ecosystem dependencies that also rely on the old API. (vuetify) |
π Linked issue
β Type of change
π Description
Read the v1 @vueuse/head post for context https://harlanzw.com/blog/vue-use-head-v1
Nuxt & @vueuse/head
I have pushed this PR up to try and get it in before the v3 stable.
The DOM patching logic is more complex than the previous implementation and it's quite possible there are issues that won't be uncovered until wide testing. So while my personal testing has gone quite well, I'll leave this as a draft PR until I have a playground ready and can do some more testing.
Next Steps
In terms of development, once this is merged then I can look at implementing the rest of the new features unlocked by this:
useServerHead
, opens the door for 0kb runtime headMigration Guide
Migration Guide
(copied from the release notes)
Please report any issues you find and they will fixed be promptly.
You may consider using @unhead/vue directly if you don't need @vueuse/head.
Verify your tags
The new DOM patching algorithm has not been tested in all possible scenarios, it's possible that there are unforeseen edge cases.
htmlAttrs
andbodyAttrs
merge strategyIf you had built your code around with the assumption that setting
htmlAttrs
orbodyAttrs
would clear the old tags, this is now different.Check the documentation to learn more.
Duplicate tags in the same entry allowed
To make duplicate tag handling more intuitive, duplicate tags are now allowed in the same entry.
Having these metas across
useHead
's will still dedupe as before.π Checklist