Skip to content
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

should @computed('attr.something.@each.foo') provide attr.something? #20

Closed
stefanpenner opened this issue May 20, 2015 · 4 comments
Closed

Comments

@stefanpenner
Copy link
Contributor

example:

@computed('attr.model.@each.{something,somethingElse}')
foo(model) {
  // I think we want model === attr.model
  // not model == some useless proxy object
}

thoughts?

@rwjblue
Copy link
Contributor

rwjblue commented May 20, 2015

@computed('attr.model.@each.{something,somethingElse}') should pass the value of attr.model in to the callback function.

We should just pass in the portion prior to the .@each or .[].

@stefanpenner
Copy link
Contributor Author

We should just pass in the portion prior to the .@each or .[].

my thoughts exactly +1

@stevesims
Copy link

I ran into this behaviour just yesterday, and frankly I was rather surprised to discover that I wasn't getting the value passed through to my computed function that I had specified as my dependent key. The behaviour exhibited was non-obvious to me and unexpected.

Yes, I do realise that the behaviour from this issue is as has been documented, but I had skipped past that part of the documentation before.

My presumption was that by specifying it as the key I'd get passed something.@each.foo, i.e. an array of those foo values. The first statement of my CP function ended up being a get for that key, and I ignored the something being passed into my function.

Had I wanted to work with something, but make sure that the CP is affected by the foo values changing then intuitively I'd have written my declaration to be @computed('something', 'something.@each.foo') bar(something) {.

@pzuraq
Copy link
Contributor

pzuraq commented Jun 24, 2017

I think this is now more of a concern with kellyselden/ember-macro-helpers, as this lib now just wraps that one as a decorator

@rwjblue rwjblue closed this as completed Jul 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants