3 ms·

For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then a

For me, being able to offer my library as a web component is kind of neat. Sure I can ask users of my library to import it then query select math inputs, then apply my library on these, and remember to apply it also on DOM change. <script type="module"> import lib from "/path/to/my/lib.js"; for (const target of document.querySelectorAll(".target")) { lib(target); } // TODO: Watch for DOM change and apply lib. <script> <span class="target">Some Input</span> Or I can simply ask them to import my web component module and use the custom element: <script src="/path/to/my/web-component.js"></script> <my-lib>Some input</my-lib> The latter certainly feels like a superior API for my users.

svieira 3y ago
Or you can do a little more work in your lib for your users and offer: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target" }); </script> If your users might not want you to watch the _whole_ DOM for performance reasons: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target", root: ".all-the-targets-show-up-here" }); </script> And if your users might already have a mutation observer in their apps: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target", observer: theAppObserver }); </script>
- runarberg 3y ago
  It may just be me, but all of these seem a lot inferior API design then a simple web component. Particularly if I’m asking my users to setup a mutation observer. Aside: Don’t you need to pass the library function into the callback while constructing the mutation observer? import lib, { mutationObserverCallback } from "https://my-lib.example"; lib({ target: ".target", observer: new MutationObserver(mutationObserverCallback), }); Honestly, this feels like so much magic compared to a simple: <my-lib>Some Input</my-lib> where I handle update in my library by listening to the slotchange event.

svieira 3y ago

Or you can do a little more work in your lib for your users and offer: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target" }); </script> If your users might not want you to watch the _whole_ DOM for performance reasons: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target", root: ".all-the-targets-show-up-here" }); </script> And if your users might already have a mutation observer in their apps: <script type="module"> import lib from "the-lib.co.uk"; lib({ target: ".target", observer: theAppObserver }); </script>

runarberg 3y ago
It may just be me, but all of these seem a lot inferior API design then a simple web component. Particularly if I’m asking my users to setup a mutation observer. Aside: Don’t you need to pass the library function into the callback while constructing the mutation observer? import lib, { mutationObserverCallback } from "https://my-lib.example"; lib({ target: ".target", observer: new MutationObserver(mutationObserverCallback), }); Honestly, this feels like so much magic compared to a simple: <my-lib>Some Input</my-lib> where I handle update in my library by listening to the slotchange event.