can.Mustache: inconsistent behavior when updating nested attributes of an Observe #441

Closed
bmomberger-reciprocity opened this Issue Jun 29, 2013 · 3 comments

Comments

Projects
None yet
3 participants
@bmomberger-reciprocity
Contributor

bmomberger-reciprocity commented Jun 29, 2013

http://jsfiddle.net/air_hadoken/Xp9K8/4/

When starting with different stub values (or no value) for an Observe's property, nested sections of a Mustache fail to update consistently for different patterns of nesting, especially around use of "this." and use of dot notation, and a few cases with "if" mixed in. There seems to be a few groups of patterns: empty list, empty string, and non list/non string values are one (though listalikes work differently when "if" is used). Empty object is the same as having an object with the child null. Null and undefined are the same. can.computes generally are consistent, though (not shown in the fiddle) if you replace a compute with an Observe, it will not work in any case.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Jun 29, 2013

Contributor

Thanks! I'm not sure if you've seen the "mustache scope" branch, but this would be the best place to get these things right as that is going to be the code that handles this stuff.

Sent from my iPhone

On Jun 28, 2013, at 5:55 PM, "Brad (Bradley) Momberger" notifications@github.com wrote:

http://jsfiddle.net/air_hadoken/Xp9K8/3/

When starting with different stub values (or no value) for an Observe's property, nested sections of a Mustache fail to update consistently for different patterns of nesting, especially around use of "this." and use of dot notation, and a few cases with "if" mixed in. There seems to be a few groups of patterns: empty list, empty string, and non list/non string values are one. Empty object is the same as having an object with the child null. Null and undefined are the same. can.computes generally are consistent, though (not shown in the fiddle) if you replace a compute with an Observe, it will not work in any case.


Reply to this email directly or view it on GitHub.

Contributor

justinbmeyer commented Jun 29, 2013

Thanks! I'm not sure if you've seen the "mustache scope" branch, but this would be the best place to get these things right as that is going to be the code that handles this stuff.

Sent from my iPhone

On Jun 28, 2013, at 5:55 PM, "Brad (Bradley) Momberger" notifications@github.com wrote:

http://jsfiddle.net/air_hadoken/Xp9K8/3/

When starting with different stub values (or no value) for an Observe's property, nested sections of a Mustache fail to update consistently for different patterns of nesting, especially around use of "this." and use of dot notation, and a few cases with "if" mixed in. There seems to be a few groups of patterns: empty list, empty string, and non list/non string values are one. Empty object is the same as having an object with the child null. Null and undefined are the same. can.computes generally are consistent, though (not shown in the fiddle) if you replace a compute with an Observe, it will not work in any case.


Reply to this email directly or view it on GitHub.

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Nov 12, 2013

Contributor

Those all seem to work in latest. @bmomberger-reciprocity could you verify at http://jsfiddle.net/Xp9K8/5/?
I think the empty list ones are correct, too because {{#first_level}}{{#second_level}}Text: {{text}}{{/second_level}}{{/first_level}} and similar things will be empty for an empty list (second_level is undefined so the text block will never evaluate). All other cases are evaluating as expected.

Contributor

daffl commented Nov 12, 2013

Those all seem to work in latest. @bmomberger-reciprocity could you verify at http://jsfiddle.net/Xp9K8/5/?
I think the empty list ones are correct, too because {{#first_level}}{{#second_level}}Text: {{text}}{{/second_level}}{{/first_level}} and similar things will be empty for an empty list (second_level is undefined so the text block will never evaluate). All other cases are evaluating as expected.

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Nov 12, 2013

Contributor

Closing this for now for the 2.0.1 release. Please reopen if issues still persist in 2.0.1.

Contributor

daffl commented Nov 12, 2013

Closing this for now for the 2.0.1 release. Please reopen if issues still persist in 2.0.1.

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