Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[✨] Add ability to customize the "@" symbol for defining the layout name for a route #100

Closed
Raiondesu opened this issue Jan 29, 2023 · 1 comment
Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation

Comments

@Raiondesu
Copy link

Raiondesu commented Jan 29, 2023

Is your feature request related to a problem?

Some environments, build systems, or code linting configs may reject or misinterpret the @ used as a layout name marker in the route name. Same can be said of some other directory structure mandates in qwik-city.

Describe the solution you'd like

An ability to customize at least the layout name marker using the qwik-city options object.

Something like this:

import { defineConfig } from 'vite';
import { qwikVite } from '@builder.io/qwik/optimizer';
import { qwikCity } from '@builder.io/qwik-city/vite';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig(() => {
  return {
    plugins: [
      qwikCity({
        structure: {
          layoutNameMarker: ':' /// Now it's possible to set layout names with `index:layout-name.tsx`
        }
      }),
      qwikVite(),
      tsconfigPaths()
    ],
  };
});

Describe alternatives you've considered

Maybe it would have been possible to allow the route to provide the layout export, like with the request handlers (onGet, onRequest, etc.), but this would overclutter the route file even more while also removing the feature of knowing the layout for the route at a glance in the file explorer when utilizing this approach.

Additional context

No response

Raiondesu referenced this issue in Raiondesu/qwik Jan 29, 2023
… via options.structure property

Add the `structure` property to the PluginOptions type and pass it wherever it makes the most sense,
in order to add the ability to add new strcture customization options down-the-line. So far, the
only option  is `layoutNameMarker` which allows to customize how the layout name is read from the
`index` filename (default is `[email protected]`, where "@" is the layoutNameMarker).

fix #2753
@gioboa
Copy link
Member

gioboa commented Oct 14, 2024

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.

@gioboa gioboa transferred this issue from QwikDev/qwik Oct 14, 2024
@github-actions github-actions bot added [STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation labels Oct 14, 2024
@QwikDev QwikDev locked and limited conversation to collaborators Oct 14, 2024
@gioboa gioboa converted this issue into discussion #176 Oct 14, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation
Projects
None yet
2 participants