[Example] - Build more than a single html page.

[matthewharwood]

Any example on how we can build more than 1 page. Doesn't have to be some crazy spa routing solution but rather just build some static pages from mogwai.

For Example:
/index.html
/about.html
/work.html
/work/post-1.html

[matthewharwood]

I want to try to build bitesize components in mogwai similar to the workflow of storybook:
https://react.carbondesignsystem.com/?path=/story/notifications--toast

obviously we don't need the whole ui. HTML files would work fine. Think this kind of falls in line with #30 render-to-string

[schell]

There is an example now in the examples directory, but I've yet to add it to the cookbook.

[schell]

Maybe I spoke too soon. I forgot that this was more about SSR than anything else.

[bryanjswift]

Re-reading this it almost looks like it is about generating HTML pages/files as much as SSR.

[schell]

@bryanjswift yes, it definitely is. The server-side mogwai node can be serialized to write a static html page. Then on the client side we can use the same node definition (the ViewBuilder) to create a Hydrator and attempt to attach all the reactivity/logic to the DOM nodes that have already been rendered by the browser.
I thought this would lead to performance gains but it's actually slower to query the DOM for elements than it is to simply create them from scratch. It's still helpful if you're trying to build an app that needs to be crawled by an indexing spider but it's not the main focus of mogwai and so it's likely to be a bit hacky. YMMV. It works though!

[matthewharwood]

@schell I'm sorry I've been out of the rust space for a while. But I recently got a prompt to remind me of mogwai. I have a hack that could help bridge the gap for performance. It def is hacky but I find it kind of beautiful way to leverage the power of the browser's web component model. I'd love to know if you think it makes sense for mogwai.

If you can explicatly know which components need to be (re)hydrated. You can create a sandwhich of a native WebComponent, MogwaiView and SerializedProps:
Psuedocode looks liek this:

   <WebComponents>
     <MogwaiView ${...mogwaiProps} />
   <SerializedMogwaiPropsScript />

or something more concrete

The catch is we'll need to declare each component that we expect to be hydrated on the client. This boundry could obviously be optout of hydration too.

export function autoHydrate(Component, name) {
  if (isClient) {
    return Component;
  }
  return props => html`
    <hydrate-root name=${name} />
    <${Component} ...${props} />
    <script
        type="text/hydration"
        dangerouslySetInnerHTML=${{
      __html: JSON.stringify({props})
    }}
    />
  `;
}

The web component is the beauty of it all, it is the the performant hook that bridges the gap between browser and mogwai. connectedCallback nvoked each time the custom element is appended into a document-connected element.
Therefore, Now using it as a free document based mutation observer.

 class HydrateRoot {
   // 
    connectedCallback() {
      console.log(this) // will refer to the wrapper and 
      mogwai.hydrate(this.nextSibling) // whatever pubic function needed to hook into mogwai
      // this avoids mogwai needing to do the dom selection.
    }
  }

Here's a more complete Javascript framework version

It 100% is a lot of work to declare all your hydration components. That said there can be conventions that developers build into making this scale a bit better. However, this affords the oppertunity to have your cake and eat it too!

[schell]

Thanks for all your thoughts here. I've been meaning to flesh out the hydration story a bit more. I'll gather my thoughts and jot them down here as soon as I can :)