[Glimmer?] Helper does not receive correct view in 1.13

[ghost]

export default function(...props) {
  var options = props.pop();
  var view = options.data.view;

  // other code
}

In <= 1.12 view would be the component the helper would be called in.
In 1.13 this changed to the controllers view.

[mixonic]

@martndemus can you give us a more complete example? I think I know what you are saying, but I want to be sure.

[rwjblue]

Is this what you are talking about:

1.12 -> http://emberjs.jsbin.com/rwjblue/529/edit
canary -> http://emberjs.jsbin.com/rwjblue/528/edit

---

I am unsure what exactly options.data.view is when rendered inside of a yielding components template in 1.12, it is not the component or the application view (though I believe that the new behavior is more correct in that case).

[mixonic]

@martndemus I believe this may have indeed changed, but we're going to view this change as a bugfix.

Robert's demo doesn't show that the view passed to the helper was the component, however whatever it was, it was not the same as the {{view}} keyword would have been at the same place. For example:

{{#outer-component}}
  {{my-helper}} {{view.name}}
{{/outer-component}}

If my-helper reads view.name, it is reasonable to expect it is the same as {{view.name}} in the template. This is how Canary works, and it does this in a predictable way across many situations. Whatever the old view was, it was inappropriate for us to pass it to the helper.

If the old behavior was passing the component as the view, it was a violation of the "transparency" of the yielded block. This is the idea that when a component yields, everything in the yield goes back to the scope the component was called in.

[ghost]

Actually what I meant is this:
canary -> http://emberjs.jsbin.com/jugumevepo/2/edit?html,css,js,output

[rwjblue]

@martndemus - Great thank you for clarifying! Definitely seems like a bug to me.

[ghost]

No problem, hope it can get fixed soon!

[ghost]

You are awesome! 👍