Shoelace + HTMX. TypeError: Cannot read properties of null (reading 'focus')

[benopotamus]

Hello!

I'm using Shoelace with HTMX (https://htmx.org), and I seem to be getting an error relating to the focus property of an sl-button. This is the the HTMX code I am using

<form hx-post="/invite-client" hx-swap="outerHTML">
        <sl-dialog label="Invite client" id="invite-client-dialog">
            
            <sl-input name="email" type="email" label="Carer's email address" value="" required="" size="medium" invalid="">
                    
            </sl-input>
            <sl-button slot="footer" variant="primary" type="submit" id="invite-client-save" size="medium">Send invitation</sl-button>
            <sl-button slot="footer" variant="text" id="invite-client-cancel" size="medium">Cancel</sl-button>
        </sl-dialog>
</form>

Which gives me this error

htmx.js:1845 htmx:swapError

htmx.js:1845 TypeError: Cannot read properties of null (reading 'focus')
    at HTMLElement.focus (chunk.YUYATEN7.js:70:17)
    at doSwap (htmx.js:3049:46)
    at handleAjaxResponse (htmx.js:3131:21)
    at xhr.onload (htmx.js:2783:21)

The line at HTMLElement.focus (chunk.YUYATEN7.js:70:17) references Shoelace

// src/components/button/button.ts
var SlButton = class extends s {
  constructor() {
    super(...arguments);
    this.formSubmitController = new FormSubmitController(this, {
      form: (input) => {
        if (input.hasAttribute("form")) {
          const doc = input.getRootNode();
          const formId = input.getAttribute("form");
          return doc.getElementById(formId);
        }
        return input.closest("form");
      }
    });
    this.hasSlotController = new HasSlotController(this, "[default]", "prefix", "suffix");
    this.localize = new LocalizeController(this);
    this.hasFocus = false;
    this.variant = "default";
    this.size = "medium";
    this.caret = false;
    this.disabled = false;
    this.loading = false;
    this.outline = false;
    this.pill = false;
    this.circle = false;
    this.type = "button";
  }
  click() {
    this.button.click();
  }
  focus(options) {
    this.button.focus(options);    **<-- line 70 is this one**
  }

I used the browser dev tools debugger to blur the button before HTMX tries to swap the HTML with the server response and it seems to stop the error occurring, but then the button that launches the sl-dialog no longer does so after the swap.

Any ideas for:

1. avoiding the focus error
2. does Shoelace support this kind of swapping of HTML?

[claviska]

I have zero experience with HTMX but this error leads me to believe you're calling focus() before the custom element has upgraded.

htmx.js:1845 TypeError: Cannot read properties of null (reading 'focus')
at HTMLElement.focus (chunk.YUYATEN7.js:70:17)

If you defer your logic, I bet you won't get that error anymore, e.g.

await customElements.whenDefined('sl-button');

// apply focus here

[benopotamus]

Ahh, I see.

HTMX is a library for swapping out parts of the DOM with HTML snippets sent from the server in response to a HTTP REST event (post, get, put, etc). It's an alternative to SPA frameworks, and transfers HTML instead of JSON.

Maybe HTMX assumes the HTML only contains elements that don't need to be downloaded from a server first. I'll try working around it.

[bryanvaz]

@benopotamus you're a genius! your HTMX extension fix for forms with shoelace compon# ents works perfectly! I'm not sure whether it's a quirk of HTMX or something to look at in shoelace in how it presents values to a form.

Link to fix for htmx: https://github.com/benopotamus/htmx-ext-shoelace

[benopotamus]

Thanks! I'm glad it helps 😄

As far as I can tell, the problem lies in the gap between htmx and web components. htmx actually has the standard html form fields hardcoded, but even if it could automatically recognise web components, the components might not work the way normal html components do (e.g. sl-rating has no name attribute 🤷 ).

Lucky for us, htmx has lots of extension hooks and making one for Shoelace was pretty straightforward 🥳

[benopotamus]

To overcome the error I mentioned in this discussion thread, I think (it was a while ago now) the solution was to change this line in htmx to:

// Temporary Shoelace+htmx fix
try {
	newActiveElt.focus(focusOptions);
} catch (error) {
	console.warn('Error when executing newActiveElt.focus(focusOptions);')
	console.warn(error)
}

Just handling the error was enough for everything to proceed smoothly. This may be fixed in htmx by now though, I haven't checked in a while 😱

[benopotamus]

@claviska I'm back with this problem again 😂. In the last 2 years ChatGPT became a thing and I asked it for a resolution and it came up with this (for WebAwesome mind you), which worked 😮

customElements.whenDefined('wa-button').then(() => {
  const WaButton = customElements.get('wa-button');
  WaButton.prototype.focus = function (opts) {
    const inner = this.shadowRoot?.querySelector('button');
    if (inner) inner.focus(opts);
  };
});

What do you think of adding something like this to WebAwesome (and Shoelace if appropriate)?

[benopotamus]

I don't think it's possible with the lifecycle events htmx exposes but I'm no expert in this. The error occurs in the swapping function https://github.com/bigskysoftware/htmx/blob/81a6e25fb9cddc2846f27f494ab816fa32fc64c0/dist/htmx.js#L1971C11-L1971C43. I tried using allDefined at the event that happens before swapping but no luck unfortunately.

For my purposes though, the code I pasted earlier works well enough for me. I'm more thinking of people who use Web Awesome with htmx and don't know how to resolve the error otherwise.

Below is the code I tried. I tried a few different events https://htmx.org/reference/#events. I wasn't sure when Web Awesome would start initialising/loading a component in the htmx lifecycle as well and beforeSwap might be too early, and afterSwap I would guess is too late as the error occurs in the swap function 🤷

<script type="module">
  import { allDefined } from 'https://early.webawesome.com/[email protected]/dist/webawesome.loader.js';

  document.body.addEventListener('htmx:beforeSwap', async (event) => {
      await allDefined();
      console.log('Web Awesome components ready');
  });
</script>

[claviska]

I'm not very familiar with HTMX's lifecycle and events, but it seems like the only async-friendly one is htmx:confirm. If I understand the docs correctly, this should intercept all requests and wait until allDefined() before proceeding:

import { allDefined } from 'https://early.webawesome.com/[email protected]/dist/webawesome.js';

document.body.addEventListener('htmx:confirm', (event) => {
  event.detail.issueRequest = (async () => {
    await allDefined();
    return true;
  })();
});

It's untested but if it works out, we can probably wrap it in a tiny export so folks can do something like this:

/**
 * proposal - not real yet
 */
import { htmxAdapter } from 'https://early.webawesome.com/[email protected]/dist/webawesome.js';

htmxAdapter();

[benopotamus]

That code does seem to run event.detail.issueRequest at the right time but the focus problem still occurs. I used a console.log message to see that it ran before htmx tries to do the swap function.

I shared a link to this discussion in the htmx Discord htmx-dev channel in case they have any useful info to add.

[KonnorRogers]

@claviska the problem is that HTMX expects outerHTML swapping to happen synchronously.

https://github.com/bigskysoftware/htmx/blob/81a6e25fb9cddc2846f27f494ab816fa32fc64c0/src/htmx.js#L1971

basically it goes:

beforeSwap
node.outerHTML = newHTML
// We need a hook here! After swap, but before focus. (Preferably with async support)
el.focus(options)
afterSwap

[claviska]

Welp. Sounds like an HTMX feature request.

[HanY2B]

I do think that this problem here has to be solved somehow as it points out to an unhandled state of focusable elements.
I do not think that this needs to be solved by htmx (or any frontend framework) because I think that it should be the responsibility of the component itself to know what to do when it has not been upgraded but a focus needs to be put on it.

As shoelace aims to be a replacement for plain input elements (and plain input elements are focusable at all the times), I do think that this problem is a bug within shoelace. If the element has not been upgraded and someone already wants to put focus on it, the element itself should know what to do at this state, ideally wait until it has been upgraded and then continue focusing on the correct element inside the shadow dom.

[HanY2B]

Just disabling the focusability should not be the solution.
When using with HTMX the elements must be focusable right at the start because one of the usecases with htmx is for example a form that needs to be switched based on existing input values. And to have good UX, the focus on the currently focused input element needs to be kept.

Isnt there a way to add some guardrails inside the functions themselves?
For example inside focus function - add some kind of a waiting mechanism based on the existence of the base input.
E.g. here

if (!this.input)
  //init a non-blocking wait mechanism that resolves when the element upgrades
  return
else
  this.input.focus()

[KonnorRogers]

Sorry, its been a while since I looked at this, and was confusing this with another problem.

Yea we could do:

focus (options) {
  this.updateComplete.then(() => {
    const input = this.input

    if (input) { 
      input.focus(options)
    }
  })
}

The big problem is if you do like:

slButton.focus()
nativeButton.focus() 

slButton will actually be whats focused because of the async aspect. Maybe an edge case 🤔

We could just silently fail if the internal input hasn't rendered like native elements do like you suggested.

[HanY2B]

I did a quick test with overwriting the focus function and it seems to work, at least with sl-input and sl-select.

But I have ran into a problem with sl-radio.
The radio element (at least did not find one) seems to be a bit tricky.
Since htmx tries to focus on previously focused element, and with radio elements the previously focused element was sl-radio, not sl-radio-group, then htmx tries to focus on sl-radio.
But sl-radio does not handle the focusing, but rather sl-radio-group seems to have the functionality.

I do not know whether or not this problem here is solvable. To fix this my first thought was to introduce some functionality to radio focus function to find the wrapper element and reinit its focus function, but this seems to introduce an infinite callback loop.

[MichaelWest22]

next...MichaelWest22:shoelace:focus-after-create something like this could maybe fix the issue and make all the public functions like focus, blur etc safe to be called just like native elements. Just not sure if we should just fix the focus() function or expand the fix to all similar public functions. Also probably need to do web awesome as well.

[MichaelWest22]

next...MichaelWest22:shoelace:focuse-after-create2 may be possible to add manual focus functions back to sl-radio to fix that issue. It seems the intent was that only radio-group should have focus option to do a smarter focus even though it is actually the radio that is focused. the radio may not have an input sub element to focus on like the other components but using super.focus works to set the focus to the web-component fine it seems in my manual testing.

[HanY2B]

As a side note for anyone if they still are interested in making this work properly without any workarounds. I have added a quick (and dirty) fix to this issue here-