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

rv-each loses reference to parent view model #486

Open
benadamstyles opened this Issue May 13, 2015 · 9 comments

Comments

Projects
None yet
6 participants
@benadamstyles
Copy link
Collaborator

benadamstyles commented May 13, 2015

I've tried to make sure that this isn't a duplicate issue, although I could be wrong.

The docs state that within the rv-each-* element "you can bind to the iterated item as well as any contexts that are available in the parent view".

Unless I am doing something very wrong, this is not the case, as evidenced by this fiddle which attempts to use the rv-show binder within an rv-each-* element to reference a parent property. It is not just the rv-show binder – using the rv-text binder shows exactly the same behaviour. Referencing the parent property outside the rv-each-* element works as expected.

Thanks for any insight anyone can give!

@benadamstyles

This comment has been minimized.

Copy link
Collaborator

benadamstyles commented May 13, 2015

More info I've just discovered: this error only happens if the parent property is a primitive and not an object. I've updated the respective fiddles here and here to show that everything works as expected when binding to an object on the parent model rather than a primitive value.

If this is the expected behaviour it should be documented.

@Duder-onomy

This comment has been minimized.

Copy link
Collaborator

Duder-onomy commented May 13, 2015

@Leeds-eBooks You are correct, I don't think this is the expected behavior, in the last few weeks there have been at least 2 posts
This one, #452 and this one, #480

I think that would be grounds for some documentation, maybe we should say something like:

"Put it in an object ... or else!"

Kidding, too much coffee, but seriously... How would you phrase it for the docs?

@benadamstyles

This comment has been minimized.

Copy link
Collaborator

benadamstyles commented May 24, 2015

@Duder-onomy Sorry for the delay. Wouldn't it be better to change how the rv-each-* binder works so that it works the same as other binders? Would this be possible/do-able?

@jpotterm

This comment has been minimized.

Copy link

jpotterm commented Jun 22, 2015

This is also a problem for me. I made a similar fiddle. It does seem like there must be a better way to implement the each binder.

@smiffy6969

This comment has been minimized.

Copy link

smiffy6969 commented Jun 23, 2015

This had me stumped for hours till i found this post, thanks.... yes only changes to parent properties filter through to 'each' loops... If i reference a parent value in an each loop, changes to the parent property are lost. It renders the initial value, but updates are lost. If you wrap the value in an object it works fine. Is anyone still maintaining rivets?

@benadamstyles

This comment has been minimized.

Copy link
Collaborator

benadamstyles commented Jun 23, 2015

@smiffy6969 Good question, follow this issue -> #500

I would be happy to offer my services as a maintainer, were it not for the CoffeeScript.

@smiffy6969

This comment has been minimized.

Copy link

smiffy6969 commented Jun 23, 2015

I have had to fork a copy of this anyway, as i need to force a stop location for traversing. I am bundling this into my own web components library, I offer binding per component so I need to ensure no collisions with embedded components, in components (you get some funky results if you try to do this). So seeing as I needed this, I have tweaked the traversing a little, directly in the js (oh how i hate coffee script too). If i get time I may fork this and convert the js to something more readable and try to fix this issue, but time is not on my side at the mo. ;) thanks to author for a great tool!

@blikblum

This comment has been minimized.

Copy link
Contributor

blikblum commented Aug 11, 2016

I managed to fix this issue by changing how scope resolution works. Fixes also #512
Here's the commit in my repo: blikblum@7203c10

There are also other changes but should be easy to port. The relevant code is in sightglass and removing the copy of properties in each binder.

@milonas115

This comment has been minimized.

Copy link

milonas115 commented Mar 8, 2017

HIGHLY suggest to modify the event handler method. If not, will most likely cause breakage.

      handler: function(context, ev, binding) {
		ev.$scope = binding.view.models;
        return this.call(context, ev, binding.view.models.$parent || binding.view.models);
      }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment