More robust type detection in get-key.js #290
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Recently on our Ember app we've been having issues using ember-data-storefront to retrieve some - but not all - items from the shoebox. We determined that the frontend and Fastboot were able to generate the appropriate keys for retrieval, but ember-data-storefront was sometimes trying to fetch with malformed keys. We tracked the bug down to the object constructor comparison in
get-key.js
, where sometimes our params constructor appeared like so instead of as the Object constructor:This appears to have come from ember-cli-sass using dart-sass, which pollutes the Object constructor. We still haven't determined why this only affects some uses of
cacheKey()
.Granted, this bug is not ember-data-storefront's fault, but with a small change to
get-key.js
the library can validate arrays and objects without comparing constructors. Would you be supportive of this change?