QwikDev / qwik

Instant-loading web apps, without effort
https://qwik.dev
MIT License
20.63k stars 1.29k forks source link

[✨] feat(qwik-city): Retroactively Provide Information from Edge Router Component to Parent Routes or Layout #6646

Closed genki closed 2 months ago

genki commented 2 months ago

Is your feature request related to a problem?

I believe most of the issues related to SSR dirty tasks stem from the limitation that request processing is unidirectional, from higher to lower.

The route component responsible for a specific pathname has detailed knowledge about the pathname and its parameters, whereas its parent route or layouts have less information. Therefore, the edge route component can manage tasks more accurately than others.

Consider the following path structure:

The books router knows there are items of books, and the foods router knows there are items of foods. However, the items layout does not know what specific items would be there. If the foods router wanted to add something food-specific to the parent layout, an SSR dirty task would occur. Typically, this involves adding a menu in the parent or layout.

If there were a backward way to provide information about route-specific data from the edge router up to the layout or the parents, most SSR dirty tasks could be resolved in server side.

Describe the solution you'd like

As like the dynamic document head, there may be something special exported function in each router module that pass the data from the bottom to the top. The function may be like this:

export const retroact(ev:RequestEvent) => {
  // add route specific data to the ev.sharedMap
}

Then the parent or layout components can see the ev.sharedMap to provide anything depending on the data from descendant routes.

Describe alternatives you've considered

It is difficult to come up with other solution. There should be the backward information flow, no other way can solve this issue, I think.

Additional context

No response

genki commented 2 months ago

I found the frontmatter in the ResolvedDocumentHead could be used for this purpose. It looks like for making menu of the markdown content, is it possible to be used for generic menu of arbitrary contents?