Add override and default options for cumulative configs

[brillout]

Basics

Add two new settings default: boolean | string and override: boolean | string for controlling cumulative values:

// pages/+config.js

import { Layout } from './Layout'

export default {
  Layout: {
    value: Layout,
    // Defining another layout will override this layout
    default: true
  }
}

// pages/admin-panel/+config.js

import { Layout } from './Layout'

export default {
  Layout: {
    value: Layout,
    // Override all layouts (only ancestors in the config inheritance tree)
    override: true,
    // Override all layouts (even descendants in the config inheritance tree)
    override: 'ALL'
  }
}

// pages/some-page/+config.js

export default {
  // Remove inherited layouts
  Layout: null
  // Remove all layouts
  Layout: {
    value: null,
    override: 'ALL'
  }
}

// pages/+config.js

import HeadDefaultOpenGraph from './HeadDefaultOpenGraph'
import HeadGlobal from './HeadGlobal'

export default {
  Head: [
    {
      //
      value: HeadGlobal
    },
    {
      value: HeadDefaultOpenGraph,
      default: 'open-graph'
    }
  ]
}

Groups

// pages/+config.js

import HeadDefaultOpenGraph from './HeadDefaultOpenGraph'
import HeadGlobal from './HeadGlobal'

export default {
  Head: [
    {
      // Applies to all pages
      value: HeadGlobal
    },
    {
      value: HeadDefaultOpenGraph,
      // Enable pages to override this value by using the 'open-graph' key
      default: 'open-graph' // can be any string (it's used as a unique identifying key)
    }
  ]
}

// pages/some-page/+config.js

import HeadOpenGraph from './HeadOpenGraph'

export default {
  Head: [
    {
      value: HeadOpenGraph,
      // Only override 'open-graph' group
      override: 'open-graph'
    }
  ]
}

Feedback

If you want this, add a comment below elaborating on why you need this.

[bighorik]

I would like to be able to flexibly configure this inheritance.
In my practice, a situation often happens when, for example, there are three pages:
applications/listing
applications/favorite
applications/create

For the first two, you need to use a common complex Layout, for the latter, a simpler layout. Accordingly, I would like to be able to set my own Layout for /create, overwriting the original one.

However, there are also reverse situations when you need to specify the Layout for 1 of the many pages, for example:
personalAccount/profile
personalAccount/settings
personalAccount/companies/portfolio
personalAccount/companies/stats
personalAccount/companies/about

In this case, I have added additional navigation for pages /companies - the ability to inherit previous Layouts is great

[brillout]

@bighorik Yeah, currently the only way is to do this:

applications/(complex-layout)/listing
applications/(complex-layout)/favorite
applications/(simple-layout)/create

Let me know whether it's a showstopper for you and I'll bump the priority of this ticket.

[AgentEnder]

I'd love a way to "escape" from a parent layout defined in the renderer. In my app, I have

pages/{a bunch of pages}
pages/presentations/view
renderer/+Layout.jsx

pages/presentations/view needs to not have a surrounding layout, and currently I don't see a way to get it to not be present.

I have a workaround in renderer's layout, but I don't like it:

export function Layout({ children }: PropsWithChildren) {
  const pageContext = usePageContext();

  return pageContext.urlPathname.includes('presentations/view') ? (
    <MinimumPageShell pageContext={pageContext as any}>
      {children}
    </MinimumPageShell>
  ) : (
    <PageShell pageContext={pageContext as any}>{children}</PageShell>
  );
}

Moving the presentations/view page away from presentations/index and similar would feel weird to workaround the layout inheritance

[brillout]

@AgentEnder Makes sense. I think this would be nice:

// pages/some-page/+config.js

export default {
  // Remove all inherited layouts
  Layout: null
}

[AgentEnder]

That could work, currently I divide my PageShell component into MinimumPageShell and the base PageShell as saw above. Ideally I'd be able to set a Layout that is just the MinimumPageShell

[bighorik]

@bighorik Да, в настоящее время единственный способ - сделать это:

applications/(complex-layout)/listing
applications/(complex-layout)/favorite
applications/(simple-layout)/create

Дайте мне знать, подходит ли вам это для показа, и я увеличу приоритет этого запроса.

Unfortunately, this is not suitable. I have a layout common to all pages, which at some levels of nesting of the file system must be completely overwritten. I'm using vike version 0.4.171 in production, and the lack of backward compatibility makes me cry :(

[brillout]

Unfortunately, this is not suitable. I have a layout common to all pages, which at some levels of nesting of the file system must be completely overwritten.

Can you elaborate?

I'm using vike version 0.4.171 in production, and the lack of backward compatibility makes me cry :(

The 0.4.x release branch is backwards compatible. If it isn't then I consider it a bug; elaborate if that's the case.

[alexmnv]

@bighorik Yeah, currently the only way is to do this:

applications/(complex-layout)/listing
applications/(complex-layout)/favorite
applications/(simple-layout)/create

That seems a bit excessive if there's only one page that requires a specific layout, while all the other pages use the default layout.

[brillout]

Labeling this as high-prio. I understand it's annoying, but I'd like to gauge how much and how often it's annoying in order to prioritize accordingly. The more I understand how annoying it is the more I will prioritize this.

[chrisvander]

I have a layout with a sidebar and a right-hand panel that generally is centered with a maximum width, but occasionally needs to be broken out to take up the full right hand width. Currently, I would need to redefine the typical case on every page, and only occasionally leave out the layout so the child can take up the full width.

I bet there are other cases like this, but I wonder how the default and overrides should really work. There's definitely parts of the layout I want on every page, parts that I want on most pages, and parts that I want on some pages. There's a hierarchy there and I'm not sure whether it's defaults or overrides or some other way to configure the layout.

There are also cases where I want to swap out portions of the sidebar depending on the context, and not have that be dynamic, but just a part of those page's layout.

EDIT: This no longer matters to me. I set up a custom config flag that affects the layout. This works well for me.

[brillout]

Indeed, using custom settings can be a workaround. Although note that all Layout code is loaded regardless of whether it's used then.