Riot: Support refs in tags

[steelbrain]

React supports them and they are super-cool. They make complex DOM manipulation less painful.

<div ...>
  <div ...>
    <div ...>
      <div ...>
        <span ref="something">Wow</span>
      </div>
      ..
    </div>
    ...
  </div>
  ...
</div>

console.log(this.refs.something) // <-- will point to that span

[cognitom]

Hi. I like that idea. We have some discussion on https://github.com/riot/riot/issues/715#issuecomment-115518282 .

[GianlucaGuarini]

I also like this idea, I will try include this feature in riot 2.3.0, but there is still a lot of work to do

[nippur72]

Regarding ref= I like it too, but there will be still support for id= or name= ?

[GianlucaGuarini]

I thought about it and I would like plan this switch for riot 2.4.0 that will be a bit far from the next release. Riot 2.3.0 will change a lot the codebase and I would like to avoid introducing big api changes. Let's come back on this once riot 2.3.* will become enough stable

[cognitom]

:+1: v2.4.0

[RanzQ]

Is this implemented in 3.0.0?

[GianlucaGuarini]

I thought about and probably I will not implement it in the next major release to avoid breaking changes

[GianlucaGuarini]

things are changed and this feature will land in riot 3.0.0

[avimar]

Since id= and name= already seem to be accessible via this.SomeID, what are we doing here?

GianlucaGuarini https://github.com/riot/riot/issues/1694#issuecomment-231947784

Another big update will be the use of refs instead of name or id to better scope the DOM elements queries under the same path this.refs.myDomNode

Are we _replacing_ id and name access with required ref instead? It was rather nifty that for form elements I can simply use name and then it was accessible via riot. And for other elements, if I wanted to name them, just add an ID.
I initially read GianlucaGuarini's comment as saying that IDs/names were _moving_ to be namespaced under ref -- which might help avoid conflicting names of variables, but I see that's not what he meant.

[MartinMuzatko]

There are pros and cons for that. Maybe we can stick to name and id but scope them to this.elements but this is additional brainload IMHO.

Pros:

• I don't mix it up with events anymore

<app>
    <div name="filter" onkeyup={filter}>
    </div>
    <script>
        filter(e) {
            this.filter.classList.add('expand')
        }
    </script>
</app>

• Everything is scoped (tags, opts)
• Less interference with loops (each={shortcut in shortcuts} name="shortcut"

Cons:

• More brainload, in components usually you can distinguish between events and elements with naming conventions
• Should we namespace everything now? what is left in the tag scope are events (this.filter())

I think this heavily depends on personal taste, what should belong to the local tag and what should be namespaced (like this.el)

Also, there is already a confusion between elements and tags. Since riot calls component tags but we can also select non-riot tags within our components.

Regarding the name: I personally prefer @tipiirai s suggestion: https://github.com/riot/riot/issues/715#issuecomment-115239871 with this.dom

As for this.refs, I'd associate it more with references to plain JS objects, rather than DOM objects.

[GianlucaGuarini]

@cognitom Any progress on this feature? I would like to test if removing the named id/names DOM queries we will get better performances

[MartinMuzatko]

There is still something I'm confused about:

React supports them and they are super-cool. They make complex DOM manipulation less painful.

How is this.refs.element less painful than this.element ??
How does the "usual" DOM manipulation compare to "complex" DOM manipulation with this.refs? I feel like I'm missing something here.

This has nothing really to do with support or cool, but to namespace the elements, or am I missing any other features that would get introduced with this.refs?

Please help resolve the confusion @GianlucaGuarini.

[nippur72]

I'm also confused, Riot already has DOM elements referencing by id and name, so why ref ?

BTW, React 15 has dropped support for ref with string argument. It does support only ref=function() and you have to manage the reference by yourself. I guess they did that because they are promoting a stronger type checking on components.

[cognitom]

@GianlucaGuarini sorry for my late reply. I think almost done. I'm fixing the tests, right now.

But, what I did was so simple. Just two lines, named.js and parse.js:

arrayishAdd(customParent, value, tagOrDom) // old
arrayishAdd(customParent.refs, value, tagOrDom) // new

// old
if (name === 'name' || name === 'id') {
  expr = new NamedExpr(dom, name, attr.value, tag) }
// new
if (name === 'name' || name === 'id' || name === 'ref') {
  expr = new NamedExpr(dom, name, attr.value, tag)
}

Anyway I'll send the PR ASAP. Let me know if there's anything missing.

[GianlucaGuarini]

@cognitom that's wrong. The ref should be cached in this.ref avoiding conflicts with other components properties. The idea is to remove the crap coming from the DOM that automatically gets set as component property generating stupid errors.
The name and id attributes should be removed as well. Let me know if it's too much work

[cognitom]

@GianlucaGuarini thanks for clarification.

The ref should be cached in this.ref

customParent.refs is this.refs. Do you mean this.ref instead of this.refs?

The name and id attributes should be removed as well.

OK, I'll remove them, too.
(If I haven't done in tonight, I'll let you know)

[rsbondi]

@MartinMuzatko this does 2 things, namespacing as you mentioned but also, there are other reasons to use name and id, so this would be more explicit, and not bog down in these cases.

I have seen many breakages when using a class as a selector with jquery, where one might expect class to be for layout, and someone works on the layout and changes the class and the code breaks. This would remove this type of overlapping intention.

[rongxike]

I cannot upgrade to 3.0.1 because of this refs, all of my team's projects are using this.inputID (more than 1000 lines of code). Now, it's really painful to change everything to ref="inputID" and refs.inputID

Could you please put this.inputID back to peace?

[MartinMuzatko]

@rongxike which Riot 3.x features would you need that stops you to stay with 2.6.x? 3.x introduces breaking changes - and they have all right to do so.

If you want to migrate to 3.x, you could use regular expressions to get your IDs and Names and replace them with refs.
Migrating to a new major version always means extra work. (Imagine telling Angular2 to revert to Angular1 style)
Please ask in our gitter channel if you need further support.

[sourcegr]

I think that you are over reacting...

If you begin the conversion, you will see that this is the easiest thing to
do. Transfering name=""" and id="" to data-ref.

I ported my ~12000 line of code backend for an e-shop, in about 5 hours...

There may be some other things that will set you back, but the conversion
to refs is not one of them...

---

Vagelis PapadogiannakisSOURCE DEVELOPMENT
e: [email protected], t:[phone]

45 P. Kelaidi str, Heraclion/Crete | 71306
http://www.source.gr

On 28 November 2016 at 12:14, Martin Muzatko [e-mail]
wrote:

@rongxike https://github.com/rongxike which Riot 3.x features would you
need that stops you to stay with 2.6.x? 3.x introduces breaking changes -
and they have all right to do so.

If you want to migrate to 3.x, you could use regular expressions to get
your IDs and Names and replace them with refs.
Migrating to a new major version always means extra work. (Imagine telling
Angular2 to revert to Angular1 style)
Please ask in our gitter https://gitter.im/riot/riot channel if you
need further support.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riot/riot/issues/1185#issuecomment-263232915, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADwG78nXSCxArf_zts4JMDQDyrIwt7xPks5rCql3gaJpZM4F3D80
.

[rongxike]

Thank you for your replies, i will try my best to update my codes.