Using shoelace in svelte

[danny-andrews]

Hi all,

I've been using shoelace components in a svelte app, and it's mostly been going well, but I've run into a few problems, and I'm trying to determine if it's on my end, svelte's end, or shoelace's.

It seems the shoelace components get out of sync with the svelte render process, causing some "undefined is not a function" errors. Here's an example: https://svelte.dev/repl/ba22f88b580e44b9a794005af6c4cb1f?version=3.32.1. And here's the code:

<script>
    import { onMount } from "svelte"
    import { SlInput } from "@shoelace-style/shoelace";
	
    customElements.define("sl-input", SlInput);
    const focus = (el) => {
        el.setFocus();
    };
</script>

<sl-input use:focus />

<style>
    sl-input {
        border: 1px solid black;
    }
</style>

For those of you not familiar with svelte, use:focus is a directive which calls the focus method once the node it is on has been mounted. Only trouble is, it is called before the sl-input component has fully initialized, resulting in an error written to the console: TypeError: Cannot read property 'focus' of undefined at HTMLElement.setFocus.

Wrapping the call to el.setFocus in a setTimeout works, but it's hacky and I'm trying to see if there's a better way.

On a related note, can anyone explain why methods like setFocus are async? I don't quite understand that.

Thanks!

[jaredcwhite]

Wrapping the call to el.setFocus in a setTimeout works, but it's hacky and I'm trying to see if there's a better way.

I'm not familiar with Svelte directly, but I'm guessing the code you need to run would need to be wrapped in a whenDefined promise. See https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/whenDefined

That way you're guaranteed not to be interacting with a generic/unknown HTML element.

[danny-andrews]

Thanks for the suggestion, but that didn't do it. The thing is, setFocus is being called correctly on sl-input. It doesn't fail until you get inside that method call.

// input/input.tsx
async setFocus(options) {
  this.input.focus(options);   // This line fails, this.input is undefined
}

So, it's like we're at a point the sl-input tag has been rendered to the DOM, but its children (content) has not. I wonder if there's some event I listen to.

[claviska]

This may help. It's not [currently] documented, but every component exposes a componentOnReady() function which returns a promise that resolves when the component has completed its first render.

const input = document.querySelector('sl-input');

input.componentOnReady().then(() => {
  // component has rendered
});

[danny-andrews]

Hmmm...this isn't showing up for me. Is this only @next? Or should it be in @2.0.0-beta.26?

[claviska]

It's not new, it's something Stencil adds automatically. Come to think of it, it may only be applied to the lazy loader build.

Stencil also emits an appload event on the window object. Not my preferred approach, but it may help you out in a pinch:

window.addEventListener('appload', () => {
  // stencil components have loaded
});

[danny-andrews]

No dice.

[danny-andrews]

From https://stenciljs.com/docs/methods#public-methods-must-be-async:

Developers can call methods before the implementation was downloaded without componentOnReady(), which queues the method calls and resolves after the component has finished loading.

I beg to differ. :P

[danny-andrews]

Well, I guess that's not fair: I am able to call the method. But at the time I do, this.input has not yet been set. I think stencil only defers method calls until the components's code has been loaded, not until the component instance has been rendered. Is there some internal promise to await inside methods that reference DOM nodes? Something like:

async setFocus(options) {
  await this.componentHasLoaded();
  this.input.focus(options);   // this.input will definitely be defined now.
}

It'd be annoying to add this to every method which references DOM nodes, but it seems like the only robust way to prevent undefined errors from arising when methods are called before the component is rendered.

Tbh, this seems like a flaw in Stencil's design. What component method wouldn't reference a DOM node? The whole purpose of methods is to perform some imperative action which can't be accomplished with props. That being the case, it seems to follow that methods should be deferred until after the first render, to prevent nodes from being referenced before they are set. But maybe I don't have a full understanding...

[claviska]

Is this still a problem with the latest LitElement-powered release?

[danny-andrews]

I'll try it out soon and let you know!