Exception in template helper

[hluz]

When displaying a template under a {{#each xxx}} helper, where xxx is an array of mongo subdocuments, under some sequence of events an exception is triggered:

Exception in template helper: TypeError: Cannot read property 'apply' of undefined
 at Object.helpers.(anonymous function) (http://localhost:3000/packages/manuel_viewmodel.js?hash=c6a7...

This is a weird one, and took me a while to reproduce it get a minimal repro... I can work around it, but knowing it is there triggers my OCD... and since I'm not sure it will not trip other issues, here it is. Detailed explanation of the sequence of actions that trigger this can be found as comments to the code in the repro: https://github.com/hluz/vmArr.git

[ManuelDeLeon]

If this has something to do with the latest changes I'm going to lose it, I really will...

I'll check it out tomorrow. Thanks for the help. On Apr 1, 2016 11:36 PM, "hluz" notifications@github.com wrote:

When displaying a template under a {{#each xxx}} helper, where xxx is an array of mongo subdocuments, under some sequence of events an exception is triggered:

Exception in template helper: TypeError: Cannot read property 'apply' of undefined at Object.helpers.(anonymous function) (http://localhost:3000/packages/manuel_viewmodel.js?hash=c6a7...

This is a weird one, and took me a while to reproduce it get a minimal repro... I can work around it, but knowing it is there triggers my OCD... and since I'm not sure it will not trip other issues, here it is. Detailed explanation of the sequence of actions that trigger this can be found as comments to the code in the repro: https://github.com/hluz/vmArr.git

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/223

[hluz]

No, don't stress. I don't think it has anything to do with bindings or event listeners...

and thank you for your package.

[fvpDev]

212; has been happening for me for a while, actually. I'm gonna check out this repro. Thanks for making one.

[ManuelDeLeon]

Very nice repro.

It's clear that I have to return undefined to Blaze if the view model doesn't have the property. Right now it assumes that if the first view model has a property then the second one will too. That's not the case for inherited properties.

I was thinking of giving out a message saying the inherited properties changed but that will probably be more of a nuisance than anything.

I'll fix it soon. On Apr 2, 2016 6:13 AM, "Fedor Parfenov" notifications@github.com wrote:

212 https://github.com/ManuelDeLeon/viewmodel/issues/212; has been

happening for me for a while, actually. I'm gonna check out this repro. Thanks for making one.

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/223#issuecomment-204704491

[ManuelDeLeon]

Fixed on v4.0.12

Note that you can still get into trouble if your view models are inheriting properties from objects which have different properties. You can still create a situation where the Blaze helper always returns undefined because the view model doesn't know about the properties by the time the helpers are set. I wouldn't be able to do anything about it.

If the objects you're inheriting properties from have different sets of properties then you should explicitly declare the properties in the view model. In this case you should add items to showGroup (even though it works without it).

[ManuelDeLeon]

Just to clarify, in the case of this repro the showGroup view model is inheriting from two objects with a different set of properties:

Groups.insert({
    cd:"A",
    name:"name A"
});
Groups.insert({
  cd:"B",
    name: "name B",
    items: [{name: 'item1'}, {name: 'item2'}]
});

In this case B has items while A doesn't.

[hluz]

Thanks for looking into this so quick. I should have described it as "tricky" rather than "weird"... v4.0.12 fixes the exception but it now produces the wrong results (the same repro will do).

Select "B, and then "A" (without selecting "none", which has the effect of removing the showGroup template). In this case, when showing "A", the items helper does not get removed from the viewmodel and still returns [{name: 'item1'}, {name: 'item2'}] even though object "A" has no item property.

Update: Please note, the problem does not happen if the first selected object is "A". If you select "A", then "B" and then "A" again, it will all behave as it should...

Interesting though, if template showGroup has no own properties defined (i.e., all are inherited) then it behaves properly (which may indicate that a fix may be possible).

I think this resulting behaviour is worst than before (which could be fixed by just adding a items property explicitly in the viewmodel as you mentioned). Can you please re-open this?

[ManuelDeLeon]

Believe it or not it's working as designed.

The problem is that you're taking 2 things which are problematic by themselves and putting them together. You're using #with and inheriting from a collection with different number/kinds of attributes. I don't recommend doing either of those and, as you can probably tell, I really don't recommend using them at the same time.

In your case when you select B, the view model inside the #with displays the items correctly. When you switch to A, the view model stays the same but it loads the properties from the new context (document A). Here's the problem, the view model already has items so when the context changes the view model loads the properties from the context (cd and name) and leaves items as it is.

[hluz]

Ok. I have no unsurpassable problem in the real app (this repo is very contrived to isolate the issue). And thinking about how viewmodel does things it makes sense. Maybe some note on the docs to highlight this to unsuspecting users?

Thinking to myself here: what would be good (don't know if achievable) is a way to separate/identify between inherited properties and non-inherited (defined in the current viewmodel)... the way it stands we can probably have scenarios where a component viewmodel can inadvertently have a property overriden by a change made to the parent component viewmodel by adding a property with a same name that already exited in the child component...

[ManuelDeLeon]

I thought of that but it sets of a bunch of alarms in my brain. I may warm up to the idea later. On Apr 2, 2016 9:46 PM, "hluz" notifications@github.com wrote:

Ok. I have no unsurpassable problem in the real app (this repo is very contrived to isolate the issue). And thinking about how viewmodel does things it makes sense. Maybe some note on the docs to highlight this to unsuspecting users?

Thinking to myself here: what would be good (don't know if achievable) is a way to separate/identify between inherited properties and non-inherited (defined in the current viewmodel)... the way it stands we can probably have scenarios where a component viewmodel can inadvertently have a property overriden by a change made to the parent component viewmodel by adding a property with a same name that already exited in the child component...

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/223#issuecomment-204861598

[fvpDev]

Has there ever been a scenario in programming where inherited and non-inherited props have had to be separated?

[ManuelDeLeon]

All the time for me. Like a view model for a template that is inside an each block, and I want to define more UI related properties. On Apr 3, 2016 7:49 AM, "Fedor Parfenov" notifications@github.com wrote:

Has there ever been a scenario in programming where inherited and non-inherited props have had to be separated?

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/ManuelDeLeon/viewmodel/issues/223#issuecomment-204981368

[fvpDev]

I guess it's just too early for me to wrap my head around it right now lol