framework level support to reuse static parts of ssr

🚀 feature request

I already have something running, but without first level framework support, it introduces footguns and boilerplate.

As an example lets use https://angular.io/. Look at the footer:

Thats completely static. It’s a waste to 1) ship that again via javascript & 2) render it again via javascript. When it’s already right there in the browser (now ignoring that angular.io neither uses ssr, nor works without javascript - but our page does).

What I’d like to have was something like a static directive:

<footer *static></footer>

Now this is what the framework could do:

• the server
  • flag all styles that are created inside <footer *static>...</footer> for reuse in the browser
• the compiler
  • throw an error if you do anything dynamic inside - like adding an event listener
  • create a dynamic component of the insides and put that into a seperate chunk, that is only loaded, when ssr is missing. Of course I could create an NgModule and bootstrap that via ngComponentOutlet. But it would be so much nicer, if the framework would handle that
• the browser
  • pick the ssr styles
  • pick the ssr DOM
  • if ssr is missing, load the contents async and render it

–

I mean, if you use ssr, you already optimize the page to work without javascript. And most of our page does. We intentionally use urls instead of click handler most of the time. Or hidden radio buttons for accordions and checkboxes for switches. We could use event bubbling to bind click handler on a static container to support pushState navigation on static content.

With native support with something like above we could stencil out huge chunks of the page.

[sod]

It’s not yet in production, so this directive contains debug code. But it looks like this:

I wrote this SsrRecycleDirective: https://gist.github.com/sod/97178a8650662300983f6ca08db178b7

The SsrDocumentService is used to search in the ssr dom. We already detach it from the DOM before angular kills it, so we can still access it.

It’s used like:

@Component({
    template: `
    <div *rySsrRecycle="'footer'">
        <ng-container *ngComponentOutlet="footer$ | async"></ng-container>
    </div>
`)
export class AppComponent {
    public footer$ = from(
        defer(() => import(/* webpackChunkName: "lazy-footer" */ './component/footer.component')
            .then(module => module.FooterComponent)),
    );
}

I am curios to know though how are you actually removing the static components from the final bundle browser application?

Thats how the footer is detached from the main bundle. Via

        defer(() => import(/* webpackChunkName: "lazy-footer" */ './component/footer.component')
            .then(module => module.FooterComponent)),

it’s moved by webpack to a chunk called lazy-footer. The footer mustn’t be inside any NgModule thats imported by the rest of the app. It works isolated by having it’s own NgModule. Got that trick from https://medium.com/angular-in-depth/lazy-load-components-in-angular-596357ab05d8

ssr

If the ssr encounters that directive, it’ll just render as-is and add the id="ssr-recycle-footer" to that element.

browser

If the browser encounters that directive, it’ll search the DOM for #ssr-recycle-footer, and if that exist, move it to that place.

–

You can extrapolate that scheme to all parts of the page. PushState navigation stil works through another directive, that captures click events, as they bubble upwards.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}