$refsArray helper

[KevinBatdorf]

Pretty simple actually, but how's the naming here?

Alpine.addMagicProperty('refsArray', el => {
  return Array.from(el.querySelectorAll('[x-ref]'))
})

https://codepen.io/KevinBatdorf/pen/dypbMra

[HugoDF]

allRefs? refList?

[KevinBatdorf]

You think we could extend the default behavior even and have the best of both?

[KevinBatdorf]

a lot of users are just cut-paster, they don't read the readme

My initial thought too.

We could PR Alpine to remove $refs and remove it from the docs, and add a note to instruct people to come here. Kind of a bold thing to do though 😏

[SimoTod]

$betterRefs 😜
The PR to Alpine is probably too much. It should go through a private channel first to make sure Caleb is okay with that so it doesn't look like we are stepping on his feet.
So we have these possible paths:

• we use a different name (exact name TBC)
• we use $refs, extending the current implementation, we make clear in the readme what is going on but we don't touch Alpine
• we ask Caleb, if he agrees we implement the above and after a transition period we PR something to remove refs from core.
• we extend refs to support all()

I think I'm going to sleep on it.

[SimoTod]

Should we also support references using the same name?

<div x-ref="foo">one</div>
<div x-ref="foo">two</div>

$getRefs.foo would return [<div x-ref="foo">one</div>, <div x-ref="foo">two</div>]

[SimoTod]

P.s. Although it's tempting I think we shouldn't use the same name to avoid confusion and conflicts in the future

[KevinBatdorf]

Should we also support references using the same name?

I think we should support that, yes.

For the name, we can start with anything for now and if it ends up being more popular than $refs we can just alias it later on, maybe even alias it via a config flag or something.

We could even just do the full version,$references