We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
I believe you meant to serialized s not t in that case, otherwise your cache key will always be "string", please check.
The text was updated successfully, but these errors were encountered:
@vsumitra Ouch! Thanks. Fixed. Must have crept in during last round of optimization. Added a unit test to prevent that happening again.
Sorry, something went wrong.
Hi I think this was the intent, there isn't any reason to strigify a string type. plus there not way to utilized p.
var key = t === "number" || t === "boolean" || t === "string" || t === "undefined" ? a : !p ? JSON.stringify(a) : p(a);
@vsumitra It is absolutely the case there is reason to stringify a string type. Many memoizers actually make a semantic error and treat the memoization of "1" and 1 the same. It is ironic there was a bug in nano-memozie that made an even worse error. See this article: https://codeburst.io/a-key-to-keys-when-javascript-keys-dont-match-ab44c81adc87
Does it make sense to deprecate affected versions?
https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions
@tokland Thank you. Done.
anywhichway
No branches or pull requests
I believe you meant to serialized s not t in that case, otherwise your cache key will always be "string", please check.
The text was updated successfully, but these errors were encountered: