[WIP] feat: minimal plugin system PoC

[ramboz]

Use case

As a developer, I'd like to have a minimal plugin system so that I can organize common features into individual opt-in plugins that I can re-use across projects.

Driving principles

• Protection of the loading sequence (Eager, Lazy, Delayed)
• Separation of concerns
• Increase code testability
• Keep PIS score at 100

Technical

• plugins can be loaded via the await withPlugin(<path>, <options>) method
• protect the loading phases by moving the logic inside lib-franklin.js
• Offer pre/post hooks for the Eager/Lazy/Delayed phases so plugins can inject logic at the most appropriate moment in the loading lifecycle
• pre/post hooks get the options object as well as a map of plugins that expose an API. For instance

  // this isn't publicly exposed and only available to direct importers
  export function aMethodNotExposedInTheApi(…) { … }
  
  // this is publicly exposed and passed down in the pre/post hooks
  export const API = {
    aMethodExposedInTheApi: (…) => { … } 
  }
  
  // defining a running before the Eager phase
  export async function preEager(options, plugins) {
    // options.myOption
    // plugins.myPlugin.myMethod(…)
  }

• Plugins can expose a limited API usable via const myApi = await withPlugin('./plugins/myPlugin.js', …);
• Simple eager/lazy/delayed hooks in the project via the usual load* methods and a configurable delayed timeout:

  async function loadEager(doc, options) { … }
  async function loadLazy(doc, options) { … }
  async function loadDelayed(doc, options) { … }
  
  init({
    loadEager,
    loadLazy,
    loadDelayed,
    delayedDuration: 3000
  });

• RUM, decoration and placeholders logic extracted as plugins
• Leveraging <link rel="modulepreload"> for the plugins to speed up page load
• All plugin methods are executed with a context that gives access to the main lib-franklin utils (via this)

The loading sequence will be:

• init of all plugins
• preEager of all plugins
• loadEager for the project
• postEager of all plugins
• preLazy of all plugins
• loadLazy for the project
• postLazy of all plugins
• … configurable timeout … 3s
• preDelayed of all plugins
• loadDelayed for the project
• postDelayed of all plugins

Performance comparison with main

Fix #137

Test URLs:

• Before: https://main--helix-project-boilerplate--adobe.hlx.live/
• After: https://poc-plugin-system--helix-project-boilerplate--adobe.hlx.live/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[ramboz]

Some other ideas to explore:

1. Expose a chainable object, instead of individual methods:

   Franklin
     .withPlugin('./plugins/foo.js', { … })
     .withPlugin('./plugins/bar.js', { … })
     .init({
       loadEager,
       loadLazy,
       loadDelayed,
     });

2. Alias pre* in the plugin to load*, so that plugins that don't need both pre and post hooks are closer to the project's APIs
3. Add option to make some plugins "blocking" if they are needed in the eager phase, versus non-blocking (by default) if they are only needed in the lazy phase:

   await withPlugin('./plugins/foo.js', { … });
   withPlugin('./plugins/bar.js', { … });

   or maybe via options { isBlocking: true } or similar
4. Add plugins pre-loading via Link headers

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[trieloff]

I think this breaks the advanced RUM functionality (Intersection Observer)

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[ramboz]

@trieloff, @kptdobe I think I addressed all the concerns you had. Do you see anything else that would need some love here?

I don't want to spend too much time working on bumping test coverage if you still have concerns with the underlying proposal.

[aem-code-sync]

Page	Score	PSI Audit	Google
/

[trieloff]

Why don't we try this in a project and see if the benefits of maintainability pan out?

[ramboz]

@meryllblanchet Maybe something to test with one of your projects that are in the pipeline?

[meryllblanchet]

Sorry @ramboz I missed that notification - definitely, let's try this at customer project level first!

[ramboz]

Closing in favour of a more lightweight version in #254