Supporting muliple refs

[thiagomajesk]

Hello guys!

I wanted to restart this discussion because I think it could be nice to have more ways to reference elements in Alpine. This is a continuation on top of this issue where I proposed a new option for the x-ref API.

The new option would allow the user to specify a named x-ref. This would allow multiple refs to be grouped in the same placed and referenced later on. For example:

<span x-ref:items="foo">
<span x-ref:items="bar">
// $refs.items["foo"]
// $refs.items["bar"]

And a shorter syntax:

<span x-ref:items>
<span x-ref:items>
// $refs.items[0]
// $refs.items[1]

I know that the x-ref attribute is probably going to change in the next version. But even if that happens, I'd like to discuss the possibility of having at least some kind of syntax that enables this workflow. A common workflow for submitting array values in forms without breaking the "native" API is:

<input type="text" name="items[first]" />
<input type="text" name="items[last]" />

PS.: Notice that I'm not talking about keeping state of refs. Since those are evaluated at runtime, the only thing that must be done is grouping them together (the implications was made a little bit more clear in the previous issue).

[ryangjchandler]

I'm not a fan of the x-ref:items syntax - I'd prefer something like x-ref="items.foo" and x-ref="items.bar".

[thiagomajesk]

Hi @ryangjchandler! Bear in mind that this is just a draft. I'm not trying to push any particular syntax.
So, feel free to propose other ways that makes sense to the Alpine code base and reflect the framework's philosophy better.

However, an advantage of the x-ref:items syntax is that it follows a pre-establish structure of other directives (like x-on): x-{directive}:{target}.{modifier}. Also, the shorter syntax allows grouping refs without having to specify a key.

The reason I find this is important is that right now, the only alternative we have is binding x-ref dynamically and there's no way to reference what's bound without the key itself, for example:

<li :x-ref="todo.name">

It's not possible to iterate on a group of elements bound to this ref if I don't care about the keys:

<template x=for"items in $refs[??]"></template>

PS.: I'd love @calebporzio take on this

[SimoTod]

I think some real world examples (codepens?) where this is needed would help Caleb make a decision.

[thiagomajesk]

Hi @SimoTod! I don't know if you remember, but we had this interaction before 😅.
The linked issue goes in more detail, but as a general idea, any use-case where you need to dynamically reference nodes is valid. This is a very simplistic example:

<div x-data="MyTodoComponent">
    <button @click="markAllDone">Mark all done!</button>
    <ul>
        <template x-for="todo in todos">
            <li class="todo" x-text="todo.name" @click="markAsDone"></li>   
       </template>
    <ul>
</div>

<script>
    document.querySelectorAll("todo").forEach((el) => { 
          // Do some work with the elements
     })
</script>

Right now, it's not possible to reference the <li> nodes without putting some kind of class in each <li> and then querying the whole DOM. Being able to do something like this would help:

<div x-data="MyTodoComponent">
    <button @click="markAllDone">Mark all done!</button>
    <ul>
        <template x-for="todo in todos">
            <li x-text="todo.name" @click="markAsDone" x-ref:todos></li>   
       </template>
    <ul>
</div>

<script>
    $refs.todos.forEach((el) => { 
         // Do some work with the elements
     })
</script>

<div x-data="MyTodoComponent">
    <button @click="markAllDone">Mark all done!</button>
    <ul>
        <template x-for="todo in todos">
            <li x-text="todo.name" @click="markAsDone" :x-ref:todos="todo.id"></li>   
       </template>
    <ul>
</div>

<script>
   el = $refs.todos["1"]
   // Do some work with the elements
</script>

This is essentially very useful for dealing with cases where you have an umbrella component to deal with a list of children, like lists, tables, trees, etc. It's exactly the same reason we have $ref: The convenience of not having to query the DOM more than we need to.

PS.: It's just an augmentation of the x-ref capabilities. I don't see any breaking changes tbh.

[SimoTod]

I do remember and you know my position so I'm not going to add noise to this thread. :)
Caleb's view is to keep alpine as small as possible unless the feature adds value so examples usually help him understanding if a new feature solves an existing problem.

[SimoTod]

I've created an example using checkboxes for clarity. It's more verbose but it does what you need with the current syntax: https://codepen.io/SimoTod/pen/zYrZqjq

Bear in mind while you are pitching it that Caleb intends to remove x-ref and use the standard ref attribute (which needs to follow the spec so ref:something won't be a valid option). Good luck.

[ryangjchandler]

Precisely that, I'm thinking in the scope of v3, the items.foo syntax will be attribute compliant. I can see some benefits to having this, over manually getting the elements.

[thiagomajesk]

Yes @SimoTod of course. That's why I've not pinned down any specific syntax, just the functionality itself.

I'm aware that V3 will bring some changes, and I covered that in my first post 😄. There's similar functionality/ convention with input names, so maybe we could take that into consideration also.

Just to be clear: I know that this is possible to be done in the current syntax, you can also discard x-ref completely and just query the DOM directly if you don't want to use it. But it's clearer and less verbose to use it.