Open tobyzerner opened 6 years ago
This probably depends on the Webpack transition being complete, right?
And :+1: :clap: :man_dancing: for finding a way to render a non-interactive skeleton markup on the server.
The low hanging fruit (and likely first attempt) will be adding editor
as a frontend (and within it, importing from flarum/....
instead of ../...
to avoid duplicate common component code).
Then, we'll need to create:
Application
that can lazy load files (app.load(URL).then()`)app.composer.editor
, and whose only action would be calling:
app.load(URL_FOR_EDITOR_BUNDLE).then(() => {
// Replace `app.composer.editor` with ComposerState (actually we might want to do this in the initialization step of the
// executing the method call / get / set that was called on the new `ComposerState` instance.
})
We'd need to figure out how this works with initializers. Maybe we could figure out something that works with flarum/issue-archive#169?
Our JavaScript payload is quickly becoming quite large, especially when you have a bunch of extensions enabled. This will affect page load times and is something we should address. There are a few things we can do here:
The easiest place to start is to lazy-load text editor related code, like the TextFormatter preview, formatting buttons, punycode, and the emoji list. This code is large but is definitely not required for the page to be rendered. We can load this as a separate JS file asynchronously when the page loads, so it's ready to go when the composer is invoked (or if the composer is invoked before it has loaded, display a little loading spinner).
It may also be possible to split the app into a few chunks (global, discussion list, discussion, user page) and load global + whichever chunk you start on synchronously, and the rest asynchronously. However, this will require much more thought and planning, especially considering how extensions work to import, extend, and use certain modules when they boot.
(unrelated to this particular issue, but worth mentioning) Render a basic HTML structure on the server-side (for SEO content) which roughly matches that produced by the JS app. It makes sense to do this anyway, to give non-JS users the best reading experience possible and leverage the CSS that we have written already. In terms of speed, if we do this we don't have to hide the SEO HTML while waiting for the JS assets load. When the JS has loaded, it will re-render the interface, filling out all the bits that are missing in the SEO HTML.