A way to pass the whole frontmatter to vue components?

[why-trv]

The module allows binding frontmatter props to vue components as documented here: https://content.nuxtjs.org/writing#vue-components.
But is there a way to pass all frontmatter data as a single object? I could wrap all data in an extra prop, but would like to avoid unnecessary nesting.
I've also found out that using doc actually works, like so - <product-content :product="doc"> - but I don't see it documented anywhere.

What is the recommended way to do this?
Thanks

[nozomuikuta]

@amethystdeceiver

As far as I checked code of Content module, all the properties in front matter are expanded into an object when the file is parsed (link).

After that, the object is expanded again into document object when being inserted to database (link).
Scheme of this document object is what is described in the lead section of Writing content page.

So, I'm not sure why you could succeed in using doc object, since you don't provide the surrounding code.

I've also found out that using doc actually works, like so - - but I don't see it documented anywhere.

Just in case, Isn't is that that your ProductContent component is not written in a markdown file but just used next to NuxtContent component? 🤔

[AlexanderBelokon]

@nozomuikuta

It works the way it does because of the way props are passed to a subcomponent in NuxtContent component:

content/packages/content/templates/nuxt-content.js

Line 49 in b25d4db

obj[key] = value in doc ? doc[value] : evalInContext(value, doc)

I've confirmed using the doc variable name does actually work, although I can't really say if this behavior was intended)

[AlexanderBelokon]

I've created a codesandbox to illustrate this use case if you want to see it yourself)

[nozomuikuta]

@AlexanderBelokon

Thank you for pointing it out.

By the way, if I upgrade Nuxt Content module from v1.11.1 to v1.12.0, which is released yesterday and to which your PRs (#688) is merged, it came to throw an error "doc is not defined".

Demo (CodeSandbox)

---

If I understand the situation correctly, what's happening is like the following:

In v1.11.1, the attribute value (doc as a string) is resolved to doc object in the scope (i.e. propsToData function).

content/packages/content/templates/nuxt-content.js

Line 23 in ae00569

obj[key] = eval(`(${value})`)

On the other hand, in v1.12.0, the attribute value (doc as a string) can't be resolved, because none of scope chain doesn't define a variable whose name is doc.

content/packages/content/templates/nuxt-content.js

Lines 10 to 12 in b25d4db

	function evalInContext (code, context) {
	return new Function("with(this) { return (" + code + ") }").call(context)
	}

In this part, the this inside with block is context variable, which is actually doc object passed.
JavaScript tries to resolve doc as this.doc, parent scope's doc, ..., and finally an error is thrown because of no definition.

---

IMHO, accessing doc object in markdown file should not be a feature for simplicity of usage, because it will introduce conflict if we define doc property in front matter: which doc Nuxt Content should resolve?

We may reserve the word doc and allow ourselves to overwrite it with doc in front matter, as like we already do with slug. But, overwriting slug is allowed for a case where we define JSON array, and where otherwise file name corresponds to multiple documents (documentation). The situation looks totally different to me. Having less rule would be more beneficial in developer experience.

[AlexanderBelokon]

@nozomuikuta

You understand everything correctly.

I agree with your assessment that exposing doc would not be great from a simplicity standpoint. Moreover, I think that components should generally be reusable, and forcing a component to be dependent on the schema of a nuxt-content document would require a lot of unnecessary maintenance, since the schema can change easily, as well as reduce reusability, since the schema will probably be different for different documents (or become different over time).

[nozomuikuta]

@amethystdeceiver

So, to summarize, there seems no legitimate way to achieve your goal: passing all front matter data as a single object.

As I pointed out above, the way you found (i.e. using doc as an attribute value in markdown file) will break when you upgrade version of Nuxt Content module in your app.

---

Here, again, the current situation is like below:

With Nuxt Content v1.11.1 or below, any attribute values (as string) are evaluated by global eval function inside propsToData function. This means that any attributes whose name is not defined in front matter are evaluated in the scope of propsToData function. In other words, it is possible to get any variable in the scope, not only doc, which I guess was a bug.

As of Nuxt Content v1.12.0, any attribute values (as string) are evaluated inside a function whose this context is doc. This change is to improve reactivity of data (#688). As a result, it became impossible to resolve doc attribute value (as string) to the current document object.

---

@atinux @benjamincanac

Do you have any thoughts on this issue?

[why-trv]

@AlexanderBelokon @nozomuikuta

Thanks a lot for your detailed responses!
That was expected. I'll find a better way to do it :)

[nozomuikuta]

Let me close this issue sine it has been not active.
Please open another issue and refer to this issue as needed. 🙌