2 ms·
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: ".tar
by 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 agoIt 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.