[v3] Live reload only updates the first collection when a file belongs to multiple collections

[maximepvrt]

Environment

• Operating System: Darwin
• Node Version: v20.18.0
• Nuxt Version: 3.15.1
• CLI Version: 3.18.2
• Nitro Version: 2.10.4
• Package Manager: [email protected]
• Builder: -
• User Config: devtools, features, future, modules, colorMode, ui, runtimeConfig, content, routeRules, nitro, css, plausible, $production, linkChecker, sitemap, compatibilityDate
• Runtime Modules: @nuxt/[email protected] (35d9af7), @nuxt/[email protected] (85010c1), @nuxt/[email protected], @nuxtjs/[email protected], @vueuse/[email protected], @nuxtjs/[email protected]
• Build Modules: -

Reproduction

Code Example

import { defineContentConfig, defineCollection, z } from '@nuxt/content'

export default defineContentConfig({
    collections: {
        content: defineCollection({
            type: 'page',
            source: '**',
            schema: z.object({
                name: z.string()
            })
        }),
        devenirBenevole: defineCollection({
            type: 'page',
            source: 'devenir-benevole/**/*.yml',
        }),
        blogEngagement: defineCollection({
            type: 'page',
            source: 'blog-engagement/*.md',
            schema: z.object({
                date: z.string()
            })
        }),
    }
})

Describe the bug

When modifying a file that belongs to multiple collections, only the first collection in defineContentConfig is updated during live reload. This creates issues when trying to manage a global navigation by combining multiple collections.

Expected Behavior

1. All collections referencing the modified file should update during live reload.

Additional context

Proposal

A built-in function (e.g., useGlobalNavigation()) to return a global navigation combining all collections would be very helpful, eliminating the need for custom merging. A function like useGlobalNavigation() could return a unified structure of pages with essential metadata (title, path, etc.) from all collections:

const navigation = useGlobalNavigation()

Logs

[farnabaz]

This is expected. Content module preview and HMR handle one-to-one relationships between contents and collections.
Also, it is possible to include content in multiple collections, but it is not a best practice in the current state.

We can talk about the needs and requirements of this feature.

[farnabaz]

The idea is that collections are separate entities, like (blog posts and document pages or landing pages).
Having a global navigation utility sounds nice to have, but it will have a big impact on module's database management and performance. Specially in serverless environments and cold start.

What is the usage for the unified navigation?

[maximepvrt]

Thank you for the clarification!

I understand that handling one-to-one relationships between content and collections is the expected behavior. However, I want to explain my use case to clarify why I had to create a "catch-all" collection, even though it might not be considered a best practice.

Why I Use a Catch-All Collection

To build breadcrumbs and manage my site's navigation efficiently, I rely on Nuxt UI v3. Instead of sharing individual navigations for each collection, I centralized all content into a single "global" collection. This way, I can inject and use a unified navigation in my app like this:

const navigation = inject<Ref<ContentNavigationItem[]>>('navigation', ref([]))

Concerns About Best Practices

If having a document in multiple collections is not recommended, wouldn't it be helpful to add at least a warning or even block this behavior?
For example:

1. A warning could inform users when a document matches multiple collections, suggesting that this might not be ideal.
2. Alternatively, the module could prevent adding an item to a collection if a prior regex already matches it. In this case, defining an order of precedence for collections in the configuration would make sense.

Why Unified Navigation Would Help

A built-in utility for unified navigation would simplify this process significantly. Instead of relying on workarounds like my "catch-all" collection, developers could directly retrieve a global navigation structure, improving efficiency and clarity.

Let me know if this approach makes sense or if you'd like more details about my use case!

[vmihailenco]

What is the usage for the unified navigation?

This is not about global navigation, but it would be nice to have a catch-all collection for building common UI blocks across all collections, e.g. I could add this to App.vue for SEO purposes:

const page = queryCollection('*').path(route.path).first()
const title = computed(() => page.value?.navigation?.title || page.value?.title)

useSeoMeta({
  titleTemplate: '%s - Nuxt Content v3',
  title: title.value,
  ogTitle: `${title.value} - Nuxt Content v3`,
  description: page.value?.description,
  ogDescription: page.value?.description,
})

but it will have a big impact on module's database management and performance.

Not sure how it is implemented, but maybe all collections should use the same database and then queryCollection("foo") will just use where collection = 'foo'.

[maximepvrt]

After further reflection, I think it would be better to enforce that a document can belong to only one collection. Allowing a document to be in multiple collections could create issues, especially with tools like Nuxt Studio, which might not know which schema to use when generating the visual editor for such documents.

To address this, a document should be assigned to the first collection whose regex matches it, based on the order of definitions in the configuration. This would ensure consistency and eliminate ambiguity.

As for a unified navigation utility, it could simply be implemented as a composable that calls queryCollectionNavigation for each collection and merges the results. This approach would avoid adding complexity to the module's internal database management while still offering the convenience of a global navigation.

Let me know what you think about this approach!