Would it not be a bad thing to override default-injected-variables ?
What about just creating a variable dateToBeDisplayed, so if it test as null, we know it is missing, then we can generate a debug message for owner.
Then we can use it like...
<p>Post last updated: {{ article.dateToBeDisplayed }}</p
That's certainly also a good option, although I'm not sure if it's such a bad thing to override? Nuxt Content also suggests it in certain cases: content.nuxtjs.org/writing#:~:text...
I concur.
I think my problem is more to do with the following
Override createdAt in nuxt content:
. Should I use the same date format as Nuxt?
. Are there certain edge cases where it would ignore my entry?
. Would it ever fallback to original?
Rather than delving into these cases, I think it's easier to roll my own.
Top comments (6)
Very nice example! Not too tricky to get it all working.
However. Seems like a git push change the
createdAt
date of each of the content objects.Ah you're right! Thanks. You can also add a createdAt property in the markdown properties as a workaround. But this could be tedious.
Would it not be a bad thing to override
default-injected-variables
?What about just creating a variable
dateToBeDisplayed
, so if it test as null, we know it is missing, then we can generate a debug message for owner.Then we can use it like...
`
That's certainly also a good option, although I'm not sure if it's such a bad thing to override? Nuxt Content also suggests it in certain cases: content.nuxtjs.org/writing#:~:text...
I concur.
I think my problem is more to do with the following
Override
createdAt
in nuxt content:. Should I use the same date format as Nuxt?
. Are there certain edge cases where it would ignore my entry?
. Would it ever fallback to original?
Rather than delving into these cases, I think it's easier to roll my own.
100% 😁. Thinking like a true pro.