Vue-meta: Allow direct access to `getMetaInfo()` via app.$meta

[lwansbrough]

We use standard Vue SSR. One of the things we want to be able to do is provide conditional logic for the HTTP status code returned by Vue SSR. We think vue-meta would be an appropriate place to put this, so we've added a httpStatusCode property to our metaInfo section of our page page components. Trouble is, we can't actually access this properly in our server render method. Here's what I'd like to be able to do:

MyComponent.vue

metaInfo() {
  return {
    httpStatusCode: this.myData.error ? this.myData.status : 200
  }
}

entry-server.js

router.onReady (() => {
  context.rendered = () => {
    // Pass in the state of the storage after all serverPrefetch() is completed
    context.state = store.state

    // Custom `httpStatusCode` property on the vue-meta metaInfo property
    // that allows us to set the HTTP response code during SSR.
    const metaInfo = app.$meta.getMetaInfo()
    context.httpStatusCode = metaInfo.httpStatusCode || 200
  }
  resolve(app)
}, reject)

There are potentially other use cases for being able to access the direct meta info, so I think this is a reasonable request. Thanks.

[pimlie]

Although I am all for hackability, this feels like extending vue-meta' s scope a bit. Why are you using vue-meta for this? Is it because the httpStatusCode can be set by child components as well and you need vue-meta's merge capabilities?

[lwansbrough]

I think if we look at this as a general request to have access to the raw data, we don’t have to consider the specifics of our hacky situation. But for context, we see vue-meta as a way of providing anything meta-oriented, in a more general sense. HTTP status, perhaps headers. Having access to that raw data would allow us to abuse it as we need. Right now it feels like it’s sort of artificially locked away for purity reasons more than anything.

[pimlie]

The major problem I see with exposing getMetaInfo, and thus officially supporting vue-meta to be used for otehr meta information then html metadata, is that we are possibly unleashing a whole lot of additionally needed features while vue-meta's original scope is to 'just' provide metadata elements. But I understand your point and why it could be useful.

@manniL @Atinux wdyt about this?

[manniL]

@pimlie I also think this would make the scope of vue-meta way too large.

You have route meta, the ctx (in Nuxt 2), Vuex and so on, so there are plenty of options already.

[sgtfrankieboy]

I'm not sure how making a single method accessible will make the scope of a project too large? I also don't see how it would unleash other needed features?

@manniL Route Meta isn't possible because the data is dynamic, nor does the project use Nuxt.

I personally find the ability to set the HTTP Status code through vue-meta a very appropriate action. The main reason to use the library is for SEO purposes (setting OpenGraph, description, etc.) The status code returned by SSR is just as important for search engines. Returning a 200 OK when it's actually a 404 Not Found is bad practice.

[Atinux]

Hi @sgtfrankieboy

I agree with @manniL and @pimlie, this is out of the scope of vue-meta, but I understand your concern.

Actually, you have access to this.$ssrContext inside your Vue components when server-rendered.
If you look at it, you will see a httpCode variable, default to 200 (only available with vue-cli-service serve).

Here's an example of updating it (example of <script> of a component):

export default {
  created () {
    if (process.server) { // or something similar from your setup
       this.$ssrContext.httpCode = 404
    }
  }
}

If you are using a different server, you can easily achieve the same behaviour, because the context is given to renderToString, you can see it's changed value in the callback:

context.httpCode = 200
renderer.renderToString(context, (err, html) => {
    res.status(context.httpCode)
    res.end(html)
  })

More info on https://ssr.vuejs.org/guide/bundle-renderer.html#enter-bundlerenderer

[lwansbrough]

Great solution @Atinux and I agree that your example represents the correct way to do this. Cheers!