Morph crashes when swapped HTML contains x-ref with no x-data parent

[elied]

I was working in a project with HTMX and Alpine and found that when I tried to morph an HTML fragment that contained an x-ref directive but didn't have an overall x-data parent, x-ref would crash.

CodePen with example: https://codepen.io/elied/pen/rNoQRPr

The error message is: Uncaught TypeError: Cannot read properties of undefined (reading '_x_refs')

And comes from this line in x_ref.js:
if (! root._x_refs) root._x_refs = {}

The problem is that root is undefined, since the HTML fragment doesn't contain an x-data directive.

I think this is a bug since I would expect to be able to morph in pieces of an Alpine component without needing to morph the entire thing.

I read through the morph code a bit and I understand that we need to evaluate the Alpine directives on the new fragment so that we can accurately compare the two trees. However, there is handling like this:

    if (window.Alpine && window.Alpine.closestDataStack && ! from._x_dataStack) {
        // Just in case a part of this template uses Alpine scope from somewhere
        // higher in the DOM tree, we'll find that state and replace it on the root
        // element so everything is synced up accurately.
        toEl._x_dataStack = window.Alpine.closestDataStack(from)

        // We will kick off a clone on the root element.
        toEl._x_dataStack && window.Alpine.cloneNode(from, toEl)
    }

Which makes me think that this is intended to be supported, and is maybe just a matter of copying over _x_refs onto toEl, similar to how we handle _x_dataStack?

It's also fine if this is just a limitation of morph, but any guidance or suggestions like "In general, things will work better if you always morph from a top-level Alpine component" would be appreciated!

[ekwoka]

Things will work better if you morph from an x-data.

It does seem like this should be supported though.

(On a side note, x-ref is usually a bad idea)

[elied]

Thanks for the response! I am still learning Alpine and am curious why you discourage x-ref? Does it have other "gotchas" like this?

I see it used in a lot of examples snippets so I'd like to know if there is a better pattern.

[ekwoka]

Its not so much "gotchas" in terms of alpine, more that it often indicates poor component design.

Like what exactly do you need to do where you need to keep a reference to a specific element around? More than likely there is a better what to do that.

(not always, but quite often)

I see it used in a lot of examples snippets

On the alpine docs or other places?

Mostly, x-ref, similarly to useRef in react, is an escape hatch out of the system. Sometimes necessary, but rarely so when not making more advanced libraries or explicitly integrating with third party scripts.

It's not always bad practice, but using it a lot can indicate problems in the design.

I have a few alpine application in production, and the unique uses of x-ref in components is less than 5. In ~100 components. And those ones are a bit more advanced how they're used (and I'm also pretty sure those don't really need it)

[elied]

I can see what you're saying, and appreciate the feedback!

One example in the Alpine docs that uses x-ref is the drop-down component here: https://alpinejs.dev/component/dropdown

It has two refs - one for the button and one for the panel, both used to help manage focus.

For the panel, I see you could move the x-on directive onto the panel element directly to eliminate that one, but the button seems like a reasonable use-case.

Is there a pattern you would recommend that avoids x-ref here?

[ekwoka]

Just using the focus plugin would eliminate the need for the button one, actually...

[MichaelWest22]

#4744 Have a PR up to fix this issue with alpine morph