New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Properties set in looped custom tag element event seem to be cleared by parent update #2019

Closed
jrforrest opened this Issue Oct 11, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@jrforrest

jrforrest commented Oct 11, 2016

Help us to manage our issues by answering the following:

  1. Describe your issue:

Using custom tags is covered only very briefly in the guide (http://riotjs.com/guide/#looping-custom-tags) so I wouldn't be surprised if I'm doing something incorrectly here. It appears that a property updated in an element event in a looped tag is immediately cleared by a parent update. My assumption is that the child tag is having its properties entirely overridden by the loop item context on update.

The behavior of the very shortly lived input element on link click in the provided example should demonstrate the issue, and a debugger in the child tag update event will show its properties being cleared.

Am I going too far against the grain here by trying to keep state in a looped custom tag? I'm working on a larger application which has some looped elements that are fairly complex, and keeping their state in a parent tag is going to be hard to maintain.

There's also a secondary issue of foo in the example not being set on the loop context until the first parent update. That's also causing me problems but I can isolate that for a second issue.

  1. Can you reproduce the issue?

http://plnkr.co/edit/mmuRu9HqUmCs8DCQxijU?p=preview

  1. On which browser/OS does the issue appear?

Reproduced on Chromium 53/Linux, FF 49/Linux, FF 47/Windows

  1. Which version of Riot does it affect?

Reproduced on 2.6.3 and master

  1. How would you tag this issue?
    • [ x ] Question
    • [ x ] Bug
    • Discussion
    • Feature request
    • Tip
    • Enhancement
    • Performance
@rsbondi

This comment has been minimized.

Show comment
Hide comment
@rsbondi

rsbondi Oct 11, 2016

Member

Try the next branch, just replace 'master' with 'next' in your link.

Member

rsbondi commented Oct 11, 2016

Try the next branch, just replace 'master' with 'next' in your link.

@corps

This comment has been minimized.

Show comment
Hide comment
@corps

corps Oct 11, 2016

@jrforrest
My team is using 2.6 series RiotJS and have noticed this and many other bugs with if and each attributes. The solution that seems to result in the most sane consistent behavior is to always use a <virtual> containing element with an each, and not to refer to the child context on that virtual tag, but only in children of the virtual.

<virtual each="{child, i in children}">
  <my-child child={child}></my-child>
</virtual>

corps commented Oct 11, 2016

@jrforrest
My team is using 2.6 series RiotJS and have noticed this and many other bugs with if and each attributes. The solution that seems to result in the most sane consistent behavior is to always use a <virtual> containing element with an each, and not to refer to the child context on that virtual tag, but only in children of the virtual.

<virtual each="{child, i in children}">
  <my-child child={child}></my-child>
</virtual>
@jrforrest

This comment has been minimized.

Show comment
Hide comment
@jrforrest

jrforrest Oct 11, 2016

Thank you all for the review/sanity check.

Both issues appear to be corrected on next.

@corps Thank you very much for the suggested workaround. I've had a few issues with virtual (which are already reported elsewhere) but it does indeed alleviate the fairly crippling state-clearing update behavior.

jrforrest commented Oct 11, 2016

Thank you all for the review/sanity check.

Both issues appear to be corrected on next.

@corps Thank you very much for the suggested workaround. I've had a few issues with virtual (which are already reported elsewhere) but it does indeed alleviate the fairly crippling state-clearing update behavior.

@GianlucaGuarini GianlucaGuarini added this to the 3.0.0 milestone Oct 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment