-
Notifications
You must be signed in to change notification settings - Fork 12
use normalizerFn when requested #11
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
base: master
Are you sure you want to change the base?
Conversation
Useful when deep comparison is needed Example: normalizerFn = obj => JSON.stringify(obj)
Thanks for the contribution. I made some updates to it here: https://github.com/thinkloop/memoizerific/tree/pbadenski-normalizer-fn After thinking about it further, I remembered that JSON.stringify() is an unreliable way to compare objects: https://stackoverflow.com/a/26077521/1062794. And that would be the primary use-case for this addition. A straight custom compare function would probably be better. Can you think of other uses? I hesitate to complicate the api for little good reason. |
This would be a primary use for me. I want to switch our project from https://github.com/medikoo/memoizee to this project. Primarily because of it's use of Map instead of Object. I understand that there are limitations of JSON.stringify, as a user I'm willing to accept these limitations. Otherwise, ie. without a normalizerFn, I simply cannot use memoizerific. As for custom compare fn - you'd need to give me more details. I can't see how can you combine that with use of Maps and all the performance benefits associated with them. |
I came to the same conclusion when I looked into it... May I know more about your use-case? Personally I don't have a need for custom functions like this because the objects I use for comparison I make immutable. Either I replace them completely by new objects if they are different, or they remain exactly as is, with the same reference in memory, if they are the same. When it comes time for memoization, the comparison is instant for any complexity. The comparison is shifted lower down the stack, rather than at the processing stage. Another technique if the above is inconvenient, is to wrap the memoized function with another function that does any needed preprocessing. For example, say you wanted to memoize
And now Don't these seem like better solutions? |
I like your solution with immutable objects, haven't thought of it.. It won't work in our case though I'm afraid. We're memoizing inside a webworker against objects that are being transferred as part of a message - hence, they will always be new copies. I also thought of another scenario where we use custom normalizer with memoizee - memoizing against Dates |
Hey Pawel, what about the wrapper function? It works especially well with dates. Rather than passing in a date object, you pass in each part of the date as a primitive, ex: |
I suppose you could use wrapper function for dates - I'm not a big fan applying it to this scenario, but point taken. I would still need normalizerFn it for complex objects being transferred to the webworker - which is different from the dates case. Seems that you feel much more strongly about this than I initially thought :D I'm totally fine keeping that change in a fork if you are definitely against it. :) |
:-D I try to be very judicious with APIs, there is value in being able to do 90% simply, than trying to get in the last 10% with a lot of over-engineering. The API is currently dead simple, so the bar is very low, this pull would make it significantly more complicated, so I really feel I need to weigh it. So far there are some significant negatives:
I haven't used web workers that much, why are the aforementioned techniques not possible? The purpose of this pull request is basically to transform complex objects into primitive simple types (like an equivalent string, numbers, etc.). Why is it not possible to do the transforms manually before invoking the function? |
There's three "difficult" properties of objects in our scenario:
First property makes it cumbersome to transform into function invocation (unrolling an object into 10 - 20 arguments). Second property, I believe, makes it impossible, unless I consider following:
Unfortunately this code breaks the requirement 3. |
For 1, even though you should never using stringify(), as it will cause inconsistent results, be hard to debug (especially for new devs not aware), and possibly cause huge problems (what happens if a recursive object sneaks into your object), you can always do as you suggest for 2:
3 is a proper interesting use-case. |
Useful when deep comparison is needed
Example: normalizerFn = obj => JSON.stringify(obj)