rv-each loses reference to parent view model

[benadamstyles]

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]

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]

@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]

@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 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 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]

@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]

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]

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]

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);
      }