/custom-elements-loader-prototype

Primary LanguageTypeScript

Custom-Element-Loader-Prototype

Intro

This is a rough-but-working prototype, that showcases loading CustomElements via script tags as often as you like and it will re-apply the code by internally monkey-patching the CustomElements API (for your own good!).

This can be used to either conditionally reload composable code pieces that are either natively written as Custom Elements (vulgo Web Components) or are wrapped as those or simply reload them, without a reload of the hosting web page.

Think of it as production HotModuleReplacement; but without augmenting your code, nor maintaining a deep reference to use code paths.

This will happily work together with a CDN like Unpkg.com because the code gets loaded via script tags there is also no problem with the Same-Origin-Policy at all. Even Content-Secure-Policy should be no problem, if you have proper white-lists in place.

Example

  • basically you have to just load the custom-element-loader-prototype as early as possible and then things should just work(TM):

    • add the markup for your CustomElement to your code
    • load your CustomElement the way you want to load it and define it: CustomElements.define()...
    • rinse and repeat, i.e. repeat the above steps but with an updated version of your code and remove and add the initial markup for your custom element in your app dynamically

  • see src/examples/simple-static.html for a simple example with a CustomElement fetched via unpkg

Known Limitations

  • currently only tested in a most most recentish Chrome (but the actual technique should even work with Polyfills for the Custom Element API)
  • not-memory optimized, meaning it is unlikely whether old versions of a Custom Element are properly garbage-collected
  • no event-rerouting this is in theory possible via monkey-patching .addEventListener and .dispatchEvent as well; but I'd suggest using an indirection mechanism (read: message bus) for inter-component communication.

TODOs:

  • write at least basic tests, that are running the manual integration tests(TM) automatically via Puppeteer
    • test for good impl of CE API
  • actually do not abuse TS anymore:
    • get rid of any
    • use DOM Interfaces for contracts
  • re-route attributes
  • re-route slot projections
  • do some naive comparison whether new version of CE is the same as old one...