There are some issues relating to the helpers (e.g. asyncData, getEntities etc.).

The store name is not always the entity name

• For projects we'd have something like store.state.projects.projects.
• But for the blog it'd be rather store.state.blog.articles.

The issue here is that we don't currently have any way to determine what the store name (blog) is based only on a route parameter (e.g. article).

I see a few potential solutions:

1. Just require the store name to be passed in to the helpers.
2. Store some kind of mapping somewhere on the context where asyncData can access it.

The helpers don't cover all the possibilities

We have the asyncData helper which works great for non-nested entities but I'm not so sure it will work fine for nested entities? Needs testing.

And even if it does, it will only handle the inner/child entitiy (e.g. a blog article) and not the outer/parent entity (e.g. a blog category).

Ideally we'd have helpers for all possible cases:

• Listing inner entities (blog articles)
• Listing outer entities (blog categories)
• Listing relationships (blog tags)
• Viewing a specific entity (blog article, blog category, blog tag).

The demo 404s if you view a project and then reload the page. I believe this is just because of how Nuxt static generation mode works and that we simply need to populate generate.routes.

https://nuxtjs.org/api/configuration-generate#routes

There are a few points to address relating to nested entities:

1. The structure right now for a nested and a non-nested entity is identical.
2. How can we change the structure to make it more logical and easier to parse?
3. Should there be some limit to the nesting?
4. Are relationships not technically nested entities?

Structure is identical for nested/non-nested.

Consider the current example from the README:

contents/
  projects/
    my-first-project/
      content.md

This is zero levels of nesting - there are projects and only projects.

And now consider the blog:

contents/
  blog/
    a-blog-category/
      _meta.md
      an-article.md

This is actually one level of nesting - there are categories and within them articles.

But it looks identical, structure-wise, to the example above. And this is an issue.

How can we change the structure?

The my-first-project folder isn't really doing anything for the projects. Heck, I don't even think the directory name is being used. It serves only to make parsing more difficult and to cause confusion.

We could just as well do this:

contents/
  projects/
    my-first-project.md
    my-second-project.md

And actually I think that is probably what we should and will do.

This would mean that directories are only present in the case of nesting, which allows us to remove a source option too.

Should nesting be limited?

So far my own personal use-cases are for entities which:

• represent my personal projects (no nesting)
• represent a blog (categories -> articles)
• represent portfolio entries (no nesting)
• etc.

I can't even think of a case where more than one level of nesting would be useful or necessary.

Yes, of course we could have something like categories -> articles -> comments but it makes zero sense to be storing comments using this system. The same applies to e.g. a forum (categories -> posts -> replies) - such things make zero sense for this system.

Does there exist a use-case for arbitrary nesting?

If there is, I think that severely complicates this project.

And so for now perhaps we should ask a new question:

Should we impose a limitation of only one level of nesting.

I think for now the answer will have to be yes.

Are relationships not technically nested entities?

Well yes, which complicates this further. Consider: categories -> articles -> tags.

Suddenly we do have two levels of nesting! The difference is that this "entity" does not exist as a directory or a file - only as YAML front matter within the article.

Entity metadata

What if we want or need to attach some metadata the "entities" which exist only in the YAML front matter? Clearly we can't store that in a nested way - there'd be duplication!

We need some kind of convention for this too.

Imagine you want a projects entity and a project can have many technologies and many languages (like on my website). At this stage I'm thinking it would perhaps look something like this:

contents/
  projects/
    _languages.md
    _technologies.md
    my-first-project.md
    my-second-project.md

With a _languages.md like this:

javascript:
  aliases: [js]
  description: JS is da best.

And similarly with a blog with tags:

contents/
  blog/
    _tags.md
    a-blog-category/
      _meta.md
      an-article.md

And _tags.md:

programming:
  description: Articles about programming.
music:
  description: Articles about music.

This is surely possible to achieve in a nice way, somehow. We can perhaps look at NuxtPress for inspiration.

Cannot read property 'registerModule' of undefined

We should check that the store exists since we currently depend on it!

See this issue.

Title.

Also: Maybe we can bypass Vuex entirely.

• Is it possible?
• If so, why would we want to do so?

How attributes are accessed

Bare attributes (e.g. foo)

• Within markdown files themselves.
• When iterating over an entity collection (e.g. projects/index.vue).

Namespaced attributes (e.g. attributes.foo)

• When using asyncData (e.g. projects/_project.vue).

This inconsistency is confusing and this should be changed.

This one is a bit of a pain point and for now I'm avoiding it completely because it severely complicates things.

Right now with the WIP addition of i18n support, relationships are not localised/localiseable.

If you have tags then the tags are going to be in one language and one language only, even if your e.g. blog article has translations into 2 other languages.

Reasons for supporting it:

1. For some relationships it doesn't make sense anyway, consider the "projects" source for my website which has relationships for "technologies" and "languages". I'm obviously never going to translate "javascript" or "vue" even if I do translate my projects. It doesn't make sense.
2. Right now we are basically doing something like this: { "keyword": [ "entity-one", "entity-two" ] } to relate the relationships to the entities and vice versa. This becomes more difficult if we support localisation because words are not necessarily unique anymore (i.e. a word in language A can also be a word in language B but both must be distinct tags). This severely complicates the entire system.

Reasons for supporting it:

???