-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Shared Context for Layouts #5467
Comments
Pretty sure this was closed by #5778 — sibling layouts can now explicitly inherit from the 'default' layout
|
Thanks for noticing! Closing. |
@dummdidumm Not sure that it fully solves the problem, only part of it. It still forces me to use the layout of the "default layout" and also doesn't allow me to do things down the line. This only solves it at a sibling level, but will not for inheritance. I'll update the initial issue now for the new syntax. |
You can achieve what you want like this:
|
This will then force me to inherit from the initial layout.svelte, therefore I can only extend it - but not share different logic for when it cannot extend it. |
I thought that's what you want? How would
|
Example from above: // +layout.svelte
<div class="side-default">
<slot />
</div> // +layout-lorem.svelte
<div class="side-lorem">
<slot />
</div> // +context.svelte
<script>
// Do something here for all Layouts
</script>
<slot /> If I would apply your suggested approach, I would end up with: <div class="side-default">
<div class="side-lorem">
<slot />
</div>
</div> I don't really have control of what I want to share between layouts |
If you have a default layout and do not reference another layout, that default layout also applies to all other layouts that reference it. So I still don't understand why this shouldn't be possible with named layouts. From your example: // +layout-lorem@default.svelte
<div class="side-default">
<slot />
</div> // +layout-ipsum@default.svelte
<div class="side-lorem">
<slot />
</div> // +layout.svelte
<script>
// Do something here for all Layouts
</script>
<slot /> And in your sub pages / layouts you either reference one of the named layouts to further inherit from them, or no, in which case you inherit from |
@TorstenDittmann I think you're getting tangled in the naming, with named layouts your context would become an empty root level |
I understand, but that requires developers to add a named layout to each Also in your example this part doesn't work that way:
There is no way for me to make Here is a very basic example where I should see I know that there are ways to solve this, but all of them require more steps than necessary in my opinion 👍🏻 |
In your example |
I know, but that's the point. Also when I do I can't even do In the end I would still be force to use My proposal is to have a "layout kind file" that is used under any condition, basically forced even when named layouts are used. |
I still don't understand what this makes possible that isn't already possible. If you want to go to the default layout later on, you can do something like
|
In the case that Let's take an example that is a more real world use-case: I am working on a project where layout fetches data that is required for all nested layouts that are following. That means that the layouts depend on each other. This basically is a blocker to use named layouts to some extend, since the impact on the added files and addition named layouts added to pages would hurt the readability by a lot. The first Now imagine I want to use the Achieving this with named layouts down the road is not a good solution- I would probably create a lot of dummy layouts just for the sake of allowing the inheritance. I would love to be proven wrong and there is an easy solution, but I also understand that your time is very valuable and my problem might not be that important 🙏🏻 PS: If you prefer I can prepare another Stackblitz example that is more close to my use case, where it might be more obvious. |
To clarify I understand this correctly: You want to reuse the data loading logic from the layouts, but you don't want to reuse their UI? |
Yes and no, data loading is only one part of it. It is also used to populate breadcrumbs, set title, etc. In short you could say I only care about the |
Describe the problem
In certain use-cases you might have some logic (fetching data, state, whatever) inside a
__layout.svelte
file. If you now want to share behavior with multiple named layouts on the same "level", you are forced to create a component that you can use in each of those or repeat yourself.I think especially when somebody is working frequently with very diverse layouts on a project, that can be quite repetitive.
Right now the implementation would look like this:
Describe the proposed solution
I could imagine something like a
+context.svelte
, which acts like a layout - but would act like a parent layout to the+layout.svelte
and+layout-lorem.svelte
files.Even if a
+layout.svelte
is not used on the way when using a named layout, the+context.svelte
is still applied.I am not super confident in the naming here, but I think the idea is that matters.
Alternatives considered
Though it's a very minor inconvenience, I can see room for improvement.
Importance
would make my life easier
Additional Information
I'd be more than willing to dive deeper into the implementation and draft out a RFC if there is interest 👍🏻
The text was updated successfully, but these errors were encountered: