Scaffolding Plugins

[ChristopherBiscardi]

With user-defined entry points, The entire app can be based in any view library (preact, pux(purescript), etc) with the user's choice of routing library (react-router, etc) and more.

Maybe it's worth pulling entrypoint/html/routes.js presets into a separate library. Then we can have scaffolding plugins for preact, pux(purescript), etc that supply the necessary entry points and html wrappers, etc.

[TheLarkInn]

Commenting per twitter. Maybe or maybe not my teams multipage-webpack-plugin will help to satisfy some needs required for you.

One thing to note: This plugin is designed for multipage server routed apps (from Rails, Laravel, Springboot etc.). Technically this could still work for client routed apps as well (as long as those client routes are defined through System.import() and webpack creates the dynamic chunks for them.

[TheLarkInn]

Tying zorigitano/multipage-webpack-plugin#4

[ChristopherBiscardi]

@TheLarkInn LEO is actually "server rendered" to generate the HTML files. Only difference is that the "server" is executed immediately inside a webpack plugin (mapped over a list of URLs when the bundle is emitted) rather than letting that execution happen on a Rails server, etc.

So presumably, multipage-plugin could be used to generate the entries for the client-side bundle and when it outputs some "server-renderable" objects LEO can pick those up and execute them immediately rather than letting a future server do it. This results in an "Isomorphic/Universal" static site.

[TheLarkInn]

Awesome. Then I definitely see a use case for you. Perhaps once we define our default and in-house scenarios, we can then start proposing your scenario (if the implemented options available do not suffice).

[ChristopherBiscardi]

Braindump on how to modularize LEO to make it easier to integrate multipage-plugin and introduce scaffolding plugins.

LEO Core Components

• URL Generation
• GraphQL API and database from folder of files
• Static JSON API
• Pipeline for feeding URLs to a render function (prerending)
• Client-side JS bundle generation
• HTML wrapper rendering (.html file production)
• Configuration

How can we modularize them?

• GraphQL API/Database
  • Can be broken out into it's own package which exposes a single function that returns the GraphQL schema. Should expose a "watchable" version in the sense that when files in the data folder change/are created, they get scooped up and a callback is fired with the changed data.
• URL Generation
  • At first glance, seems pretty tied to content generation from the perspective of a static site.
  • Could be user-provided; for example, by an ajax call to WordPress' API (which lists posts)
  • Maybe we just expose a function which is supposed to return the full set of URLs, and provide helpers/defaults to create that function. This would allow the user to generate URLs from the GraphQL Database package and combine them with user-defined URLs or a completely different API format, etc.
• Static JSON API
  • This is pretty cool for Relay, but doesn't require Relay since it's currently just based on hashes of the routes they are called on. Relay2 can make this more sophisticated, but that can be encapsulated in it's own "Relay data fetching" package. An implementation could be written for a Redux approach, which hydrates the redux store on first render and swaps ajax calls to look for hashed JSON files.
  • Solvable Problem: The JSON API is written out from the webpack plugin that renders the static html asset.
• Pipeline for feeding URLs to a render function (prerending)
  • I think this stays in "leo-core". The reason for that being that multipage-plugin would provide output which could be used immediately to "server-render" the assets, which needs the URL list at that time.
• Client-side JS bundle generation
  • Handled through multipage now so as to reap the benefits of multiple entry chunks, etc?
• HTML wrapper rendering (.html file production)
  • Seems like there is a template output from multipage-plugin (or provided by the user). Could just be a user-provided function that defaults to a really dumb implementation if one is not provided.
• Configuration
  • Configuration works pretty well with cosmiconfig. Will have to see where multipage-plugin ends up to see if a unified configuration is needed

---

Currently there are a couple files that are user-overridable:

• html.js
  • The HTML wrapper for a server-rendered page.
• routes.js
  • Possibly goes away because we let user's override the entry file anyway. This was only "injected" to make it easier to have a root routes.js file and a fallback, which we might be able to come up with a better solution for?

We will add the following for "advanced" use cases which include scaffolding plugins.

• entry-static
  • Entrypoint used when rendering "server side". Should be a commonjs library that exports a render() function for the body content. The output of this function will be passed to the html wrapper as a string. The html template should handle injecting the necessary JSON for the client-side app to hydrate.
• entry-client
  • Normal client-side app, which should be able to handle bootstrapping on a pre-rendered html page.

[ChristopherBiscardi]

@TheLarkInn

Perhaps once we define our default and in-house scenarios, we can then start proposing your scenario (if the implemented options available do not suffice).

Indeed. Let me know when it's useful for me to contribute that data. At the very least, I think I'll be able to take the knowledge from multipage-plugin's implementation and adjust it slightly to my needs since it is significantly more advanced than the current implementation in LEO.

[ChristopherBiscardi]

Scaffolding plugins work. Doing a Preact POC next.

[ChristopherBiscardi]

Scaffolding Plugins are merged into master (although are not in an npm release yet).