Vue 3 Plan (Recommendations)

[arpowers]

Hey guys, Is there is a plan regarding this plugin and Vue3?

Tried out v3 this weekend and this plugin was one of the sticking points as its integrated into the next Factor (Headless CMS)...

Primarily there are issues with installation and types due to the changes around Vue > createApp and so on...

[pimlie]

Hey, I have been working on vue-meta v3 for some while now but am not yet ready to release an alpha yet. You can track some of my work here (mostly the new API) but everything is still under heavy development so changes will happen ;)

[arpowers]

Looks nice, that's a good standard API for the composition stuff. Thanks, @pimlie!

Appears that production use for Vue 3 is gonna take a LOT longer (~12 months?) when you consider that all the libraries are going to have to catch up.

[arpowers]

@pimlie just a request, but would it be possible to get an alpha that has the "old" object-based API as well as new Vue 3 types.

Happy to wait on composition API stuff, but the other stuff is blocking our migration to Vue 3. If there is a way I could contribute I'd be happy to do it.

[pimlie]

Hey, I have been thinking about this but I'd rather not have to spent time supporting two versions for Vue v3. It isnt the time developing a vue-meta v2-based Vue3 version what worries me, it worries me much more that I then also have to support that for the coming time. And that would only take time away from developing a good/proper revamp of vue-meta for v3. Im hopeful I will be able to release an alpha in a month or so. It will for sure not take 12 months ;)

[arpowers]

Great! Excited to see it. As a thought, I HIGHLY recommend you don't underestimate the importance of backward compatibility.

If you plan on changing the API completely, you might as well start a new plugin rather than iterate this one.

How do I know this? My old company had 60k paying customers, I made this mistake.

[pimlie]

I fully agree with you, the whole discussion about the composition api showed this too.

That said, we cant deny that the current approach in vue-meta is somewhat flawed. And Vue3 is giving us new possibilities we didnt had in Vue2. It would be stupid to not use those possibilities and/or fix those flaws just for backwards compatibility.

Ofc I will try to maintain as much backward compatibility as possible, but cannot promise 100%. My main goal is to at least support the old data structure

[ux-engineer]

@pimlie also please take into account this new cool syntax with SFC Script Setup! 😎

[pimlie]

@ux-engineer Hey thx, but as far as I am aware thats just syntax sugar for Vue3's setup method? Or is there more to it? If not, then we will already support it (see the next branch link above, the vue-router example in that branch shows the new api)

[ux-engineer]

@pimlie that's correct, it is just an another way of writing code with Composition API. I should have defined my comment more in saying that we would like see the final examples in docs to include also this cool syntax 😋

Already glanced through your next branch's example...looking good so far 👍

I hope you are getting this new version out soon after Vue 3.0 release. Currently there are a few bottleneck packages that we need to wait for to support Vue 3 before we can go through the upgrade process ourselves... In our case it's mainly with Bootstrap-Vue, which have told they will release support 'a few days' after 3.0 comes out.

[pimlie]

Yeah, me too. Was writing tests yesterdays but ran into an issue with merging arrays which I need to look into. Was trying to omit that vmid/hid stuff up to now but have to add that back for backwards compatibility. But working with arrays is just a pain when you are trying to merge them like vue-meta does, hence why the vmid property exists atm.

For the rest the biggest missing features atm are:

• ssr support (shouldnt be that hard to add)
• onload + callbacks (might postpone this after first release)
• once (might postpone this after first release)
• skip (might postpone this after first release)
• docs

[cricketthomas]

@pimlie really excited for vue 3 support. Is there a way we could test out the next branch version?

[ux-engineer]

Vue 3.0 is stable now, jej! 🎉

How is the upgrade plan looking like?

[redrbrt]

Vue 3.0 is stable now, jej! 🎉

How is the upgrade plan looking like?

Following this thread, waiting excited the next release

[pimlie]

Please refrain from posting messages to just follow this thread, instead you can click on the Subscribe button in the right bar to follow this thread.

Unfortunately I have no new updates, had some setbacks so am still working out some kinks.

[Areskul]

I've juste made some editing to set vue3 compatibility on my local branch. Could you write some Contributing.md please ?!

[susansiow]

@Areskul What's your temp solution?

[n-kort]

It's now also possible to have a <teleport to="head"> section in App.vue (or elsewhere):

  <teleport to="head">
    <title>{{ pageTitle }}</title>
    <meta property="og:description" :content="pageDescription">

    <template v-if="img">
      <meta property="og:image:url" :content="img.url"/>
      ...
    </template>
  </teleport>

and instead of the meta stuff in a component, simply pull data from a vuex store! So for a quick (but less flexible?) solution this plugin may not be required.

[susansiow]

It's now also possible to have a <teleport to="head"> section in App.vue (or elsewhere):

  <teleport to="head">
    <title>{{ pageTitle }}</title>
    <meta property="og:description" :content="pageDescription">

    <template v-if="img">
      <meta property="og:image:url" :content="img.url"/>
      ...
    </template>
  </teleport>

and instead of the meta stuff in a component, simply pull data from a vuex store! So for a quick (but less flexible?) solution this plugin may not be required.

@n-kort Thank you for the valuable info!

[pimlie]

@n-kort That is exactly how vue-meta v3 will work, just check the next branch ;)

The added value for using vue-meta would be in managing meta data for more complex setups where your meta data originates from multiple components and not in a single place.

[borodadada]

I think this method not correct, data to head become after load page, i use SSR and for google is problem. If i set data without teleport all work fine. Vue 3 + ssr

[scratchmex]

Gridsome is waiting on vue-meta to support Vue 3 in order to release its new version. Maybe a minimum viable support for vue 3 before making breaking changes? I think you don’t need to use all vue 3 features to release its suppor. What do you think?

[pimlie]

Dont have a nice update unfortunately but just want to mention that I hear you all and spending as much time as I can/have available on vue v3 support.

[EmmanuelBeziat]

Dont have a nice update unfortunately but just want to mention that I hear you all and spending as much time as I can/have available on vue v3 support.

@pimlie though I'm impatient to have a vue3 compatible version, take the time you need and don't sacrifice your health over this. 😉

[hanspagel]

@pimlie Thanks for your work on this! We’re eagerly waiting for Vue 3 support too, it’s what holds us back from porting tiptap over to Vue 3. 👀 Anything we can do to help here? Would love to contribute!

Feel free to reach out in private if you think that’s better: [email protected]

[pimlie]

@hanspagel Thanks for the offer and sorry for the long delay.

I was hoping to publish an alpha release today but due to some things taking me longer then expected (mostly TS related) I will have to postpone that. But the vue-router example on the next branch should be fully working now (you can start it with yarn babel-node examples/server.js), including auto-updates from child components and metainfo injection from outside of a component (ie external plugin/module)

Whats still left to do for an alpha release:

• Interface for using the built-in resolver(s) (just an export should be enough)
• SSR support
• Update rollup script

What would be nice to have before the alpha release

• Docs

What is still blocking from a beta/prod release:

• A code walk through to check if we want some API's to be async instead of sync (first one that comes to mind is resolver setup's)
• Ensure feature parity & compatibility with v2
• Code cleanup
• Type fixes
• More & improved tests (coverage is about 70% atm, but especially object-merge needs more edge case testing)

Known bugs that could be blocking:

• nested collections are untested and likely broken in the object merge (but maybe not blocking because i think its mostly/only needed for esi tags so could be after v3 release)
• the same old issue as always that if you use transitions for your pages there is a delay between removing the old meta data and the new metadata which can causes a flash of the title (eg Page Title A -> Default Title -> Page Title B)

[arpowers]

SSR support is, for me, the most crucial feature. For us, the largest reason we do SSR is to render the metatags so they can be picked up with scrapers and bots.

[ghost]

What about this new repo - https://github.com/vueuse/head (Document head manager for Vue 3. SSR ready)

[pimlie]

I have finally released a first alpha version: https://github.com/nuxt/vue-meta/releases/tag/v3.0.0-alpha.0

Please expect it to be very rough still and there are no docs yet, but it is in good enough working condition that we can validate the API and see if there are still major core features missing.

If someone wants to help then I could use some help with adding the missing types and publishing them on build.

[elasticdotventures]

@pimlie Thanks for the update. I'm still trying to parse my way through vue3, very much a noob.

For useApi you reference the ./examples/vue-router HOWEVER the code within ./examples/vue-router doesn't use the new 'vue 3' vue-cli+ts createRouter syntax. Looks something like this:

import { createRouter, createWebHashHistory, RouteRecordRaw } from 'vue-router'

I can't use the vue-router example (in typescript) -- because: Object literal may only specify known properties, and 'setup' does not exist in type 'RouterOptions'. So basically stuck because I can't figure out how to get vue-meta to work within RouterOptions.

Fwiw, the way vue-gtag did the router integration using the "trackRouter()" method was stupid simple to use, I'm assuming something similar could be built for vue-meta (in the meantime i'll see what I can do)

https://matteo-gabriele.gitbook.io/vue-gtag/v/next/router-tracking

[pimlie]

@elasticdotventures Did you check the vue-router example under the next branch? In this file I use createRouter: https://github.com/nuxt/vue-meta/blob/next/examples/vue-router/main.js

Something like trackRouter could be a replacement for afterNavigation, but to be honest Im still struggling a bit on deciding whether it's really vue-meta's responsibility to do router tracking. refreshOnceOnNavigation was a config setting in v2 to try to mitigate the number of times vue-meta had to walk the full component tree to get the meta info, merge it, generate html elements and then check if that html already exists or not on client side navigation. Because of how this was implemented, it was also very easy to add the afterNavigation util because that solved quite a number of help requests we were getting. Unfortunately, afterNavigation still did not wait correctly for updates when you are using page transitions.

As v3 is using Proxies and will only update the data thats really changed, I dont think we need refreshOnceOnNavigation anymore. So that means that afterNavigation wouldnt be supported by default anymore either.

Because we never found/implemented a generic solution for detecting (and then waiting for) page transitions (which made afterNavigation actually unstable to use for page tracking), Im slightly leaning to leaving it out of v3 cause I think that vue-meta's updates are fast enough now (but should do some benchmarking probably to support this claim) to just do a nextTick in a vue-router after each guard. Or maybe frameworks like Nuxt.js should just implement some hook you can call for this.

TLDR, unless we find a generic solution to detect and then wait for page transitions so we can implement a correctly working afterNavigation hook I'll probably leave afterNavigation out of v3