Layout components

[arctic-hen7]

This issue is requesting an enhancement to the code of Perseus.
The user described the problem related to this request as follows:

Right now, Perseus' support for layout components is shaky at best. If you want to have something as simple as a header that's on all pages in your app, you have to manually add it as a wrapper to every single template. The architecture of the islands architecture won't fix this, as that's designed for making self-contained components stick around, not things with tons of new children.

The user described the issue as follows:

Perseus should support injecting layout components directly into the root of the document. This is easily doable if you eject, but not otherwise. This would be easy enough to do with an addition to the define_app! macro that allows users to pass through a Sycamore component that takes children as an argument. Then, my thoughts at present would be to put that above the router.
The only possible issue with this approach is that Perseus scrubs the element tree clean on every reload, though we could avoid this by injecting the user-given layout entirely outside what Perseus considers to be its domain, by injecting above __perseus_content. This should, in theory, work, though Sycamore may not be completely happy about the disappearing elements, I'll have to test this in more detail.

Tribble internal data

dHJpYmJsZS1yZXBvcnRlZCxDLWVuaGFuY2VtZW50

[arctic-hen7]

On second thoughts, I actually have no idea how you'd pass a component through in this way. It would have to take certain properties, and components are structs to my understanding, so I'm thinking a component trait? @lukechu10, is it possible to do this with the current Sycamore components system, or should I block this until the new primitives are released?

[lukechu10]

@lukechu10, is it possible to do this with the current Sycamore components system, or should I block this until the new primitives are released?

I'm not exactly sure what you're looking for but it sounds like https://github.com/sycamore-rs/sycamore/tree/master/examples/higher-order-components. The new system should make this easier because you could just accept a closure.

[arctic-hen7]

Ah! That sounds very similar to what I want, thanks!

[arctic-hen7]

Looking at the implementation of this, it's fairly trivial to get custom layouts working on the client-side, significantly less so on the server-side. It's doable, but I'm wondering what these actually add to Perseus. They don't let you set custom context (that will be supported through global state as per #119) and they can't generate state, so I think it's better to delegate this to islands entirely as per #4. They're much more powerful, and using them avoids all the issues of layouts (like how you have to have them on every single page).

I know I said before that islands wouldn't solve this because layouts would have children, but that's not quite true. Most layouts use something like CSS Grid these days, so a layout would probably in reality be composed of a header island, a footer island, maybe a sidebar island, and then the main content. If full layouts are desired that can wrap everything, they should be done in index.html in raw HTML. If they need to be reactive, the Perseus app should be portalled in through the shadow DOM.

Given these better and more performant alternatives, I'm going to close this.