zalari/custom-elements-loader-prototype

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...

custom-elements-loader-prototype's Issues

Enable Slot Changes

The wrapper needs to reflect changes in it's slot to the wrapped component.

This can be done, by listening to slotchanged events on the wrapper and properly updating the slot in the wrapped component.

Improve TypeScript support

TypeScript has been kind of abused (as any); I am so sorry, we should use it in a better way:

• get rid of unnecessary any and type assertions
• add additional interfaces to enable TS-based code contracts

Implement named slots

Slots can have names; those need to be reflected to the wrapped element.

For this to work, I think you need to figure out the slots of the wrapped element; that could be done by rendering it invisible / offscreen to get an actual implementation. Maybe we need to monkey-patch all DOM-adding functions, to sniff for <slot> elements...

However if a component is dynamically adding slots, we are out of luck...

Add attribute reflection

The attributes for the wrapped component, are not exposed by the wrapper.

The wrapper needs to utilize static observedAttributes() getter from the Custom Element class to reflect them back to it.

Publish on NPM

It would be nice, if this package would be published as a npm package:

• -> `@zalari-oss/ce-hot-reload-prototype``

Furthermore this should ne automated with TravisCI.