Skip to content

let unflatten iterate over sorted object keys#44

Merged
timoxley merged 2 commits intohughsk:masterfrom
lipp:fix-unflatten-depends-on-keyorder
Jul 25, 2017
Merged

let unflatten iterate over sorted object keys#44
timoxley merged 2 commits intohughsk:masterfrom
lipp:fix-unflatten-depends-on-keyorder

Conversation

@lipp
Copy link
Contributor

@lipp lipp commented Apr 8, 2016

fixes #43

sorting the object keys by length ensures that lower level objects are created first.
without this PR an empty object is created (and never replaced/extended later) thus dropping parts of the object tree.

@lipp
Copy link
Contributor Author

lipp commented Apr 11, 2016

@hughsk ping. this is serious i think.

@lipp
Copy link
Contributor Author

lipp commented Apr 28, 2016

@timoxley @hughsk ping ...

} else {
return 0
}
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note you can just return keyA.length - keyB.length

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yeah that's much better! thanks

@DingoEatingFuzz
Copy link

IMO the default lexicographic sort is better than length since it gives each key a consistent placement while still ensuring that nested keys come after the respective parent key.

Not sure if the quibble is even necessary since this repo seems inactive.

@timoxley timoxley merged commit c20048c into hughsk:master Jul 25, 2017
@yvele
Copy link

yvele commented Jul 25, 2017

Is this the breaking change from 4.0.0 ? b6633d0

PS: "this repo seems inactive"?

@timoxley
Copy link
Contributor

@yvele Correct

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

Successfully merging this pull request may close these issues.

unflatten depends on "key" order

4 participants