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

can.compute nested key behaviour inconsistency with map bindings #1231

Closed
stevenvachon opened this Issue Sep 15, 2014 · 9 comments

Comments

Projects
None yet
7 participants
@stevenvachon
Contributor

stevenvachon commented Sep 15, 2014

can.computes with attr("value.nested") do not behave the same as attr("value").attr("nested") in a map binding.

http://jsfiddle.net/prometh/La806u2d/

@matthewp

This comment has been minimized.

Show comment
Hide comment
@matthewp

matthewp Sep 15, 2014

Contributor

Should be this.attr("files").attr('length')

Contributor

matthewp commented Sep 15, 2014

Should be this.attr("files").attr('length')

@matthewp matthewp closed this Sep 15, 2014

@stevenvachon

This comment has been minimized.

Show comment
Hide comment
@stevenvachon

stevenvachon Sep 15, 2014

Contributor

Wow, thanks!

How come this.attr("files.length") doesn't work the same?

Contributor

stevenvachon commented Sep 15, 2014

Wow, thanks!

How come this.attr("files.length") doesn't work the same?

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Sep 15, 2014

Contributor

Yeah, that's what I'm wondering, too. Still think this is a bug. this.attr("files.length") is what I tried and it really should work.

Contributor

daffl commented Sep 15, 2014

Yeah, that's what I'm wondering, too. Still think this is a bug. this.attr("files.length") is what I tried and it really should work.

@daffl daffl reopened this Sep 15, 2014

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Sep 15, 2014

Contributor

@daffl or @stevenvachon can you clean up the issue? so people know what the problem is on first glance.

Contributor

justinbmeyer commented Sep 15, 2014

@daffl or @stevenvachon can you clean up the issue? so people know what the problem is on first glance.

@stevenvachon

This comment has been minimized.

Show comment
Hide comment
@stevenvachon

stevenvachon Sep 15, 2014

Contributor

Fiddle updated and original post updated. I'm not very good at simplifying issue titles, however. How's "can.compute nested key behaviour inconsistency with map bindings"? Kinda long.

Contributor

stevenvachon commented Sep 15, 2014

Fiddle updated and original post updated. I'm not very good at simplifying issue titles, however. How's "can.compute nested key behaviour inconsistency with map bindings"? Kinda long.

@stevenvachon stevenvachon changed the title from map binding across components not working to an.compute nested key behaviour inconsistency with map bindings Sep 15, 2014

@stevenvachon stevenvachon changed the title from an.compute nested key behaviour inconsistency with map bindings to can.compute nested key behaviour inconsistency with map bindings Sep 15, 2014

@whitecolor

This comment has been minimized.

Show comment
Hide comment
@whitecolor

whitecolor Sep 17, 2014

Contributor

So should attr('value.nested') work the same way as attr('value').attr('nested')? At least it never worked this way.

Contributor

whitecolor commented Sep 17, 2014

So should attr('value.nested') work the same way as attr('value').attr('nested')? At least it never worked this way.

@rjgotten

This comment has been minimized.

Show comment
Hide comment
@rjgotten

rjgotten Oct 3, 2014

@whitecolor
It never worked that way because splitting the key on periods and providing deep/recursive/nested access happens inside the call to can.Map.prototype.__get whereas the call to can.__reading is made by can.Map.prototype.attr itself, before entering that __get method.

The behavior of can.Map where both a shallow or a deep fetch are supported is non-orthogonal with the behavior where only shallow binds are applied when accessed in a can.compute. I'd surely classify that as a bug. (And it's a pretty long-lived one as well; been there since day one of computes...)

rjgotten commented Oct 3, 2014

@whitecolor
It never worked that way because splitting the key on periods and providing deep/recursive/nested access happens inside the call to can.Map.prototype.__get whereas the call to can.__reading is made by can.Map.prototype.attr itself, before entering that __get method.

The behavior of can.Map where both a shallow or a deep fetch are supported is non-orthogonal with the behavior where only shallow binds are applied when accessed in a can.compute. I'd surely classify that as a bug. (And it's a pretty long-lived one as well; been there since day one of computes...)

@justinbmeyer justinbmeyer added the bug label May 14, 2015

@chasenlehara

This comment has been minimized.

Show comment
Hide comment
@chasenlehara
Member

chasenlehara commented May 14, 2015

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer May 14, 2015

Contributor

Closed by #1696.

Contributor

justinbmeyer commented May 14, 2015

Closed by #1696.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment