-
Notifications
You must be signed in to change notification settings - Fork 86
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
Add Promise support #19
Comments
That is a brilliant idea! As mentioned on #17 I guess we should return a specific type of memoized function based on hints the user gave us const foo = memoize(bar, {type: 'promise'}) Due to JS lack of types, we cannot know a function will return a promise before running it |
BTW, let's work together on the next major version =) Will create a document and share with you The main idea is to give a function with as less checking as possible based on hints given by user |
A couple of libraries basically do an options object where So the test - per JS spec - would be as simple as:
That's literally how V8 and other browsers do it internally too. |
Yes, but this is a check on the returned value But how to know (in JS) if a function returns or not a promise before executing it? |
Oh I see what you mean. Well surely, from a memoization standpoint, it's the result that matters? So really as long as it returns the actual result (the promise) it'll work? like... if Promises are sort of their own caching - it'll always return it's data. The issue would be catching an error and not caching that. |
If the function always returns a promise, we have to return a resolved promised from cache return Promise.resolve(42) And not return 42 There is one more path we have to handle: we should not cache errors |
Well if the function returns a promise we can just cache that result either way. The resolved promise will always return the same data ( Seems... reasonably simple? |
Pseudo Code:
|
We can not make checks on the hot path It is simple and doable |
Right, I get that but, that shouldn't be a hot path...? It should only be called once - on the initial setting of data. It's the same number of checks either way on the set too ("do I have an options object and is it set to be a promise?" vs "is the returned data an object and does it have a then property that's a function?" In fact they both short circuit fast too (if the first check fails then no need for the second). So the same number of checks fire either way, and is only called once. Not sure how it's a hot path or would slow anything down (any more than the alternative anyhow). |
When would you do that check?
You have to do it on the returned memoized function, right? Or am I missing something? |
You'd do it on the initial set, basically on the returned data but NOT every time, just at the point where you cache the response. So it would only happen once. Subsequent calls would just be a simple get from cache because no matter what you get at that point it's the (correct, non-errored) result of the cache. If it's a promise then the data is already cached in that promise (and, per pseudo code above, we don't cache errors). You'd only need to re-memoize (and so run the check again) in the case of cache expiry (which isn't supported atm, pending that PR, and would have to be reworked anyhow). |
Any update on support for promises? |
It's on my backlog. |
any update on this? is this in the latest? |
I ended up having to abandon this (for unrelated reasons) so my fork is woefully out of date, no idea if this ever landed. |
Here's a workaround with the current library (in typescript). Half to help out and half for peer review in case I missed something. The serializer seems to assume a string hash, but I needed access to the arguments for the retry case, so it requires a little bit of a hack.
|
Working on a version of this on my fork now but it would be great to be able to pass in a promise and have the library return a promise that resolved to that result.
ie:
Per JS spec the official way of doing this check would be
typeof fn.then == "function"
as that makes the function a "thenable".Thoughts, concerns, etc? I may open a PR if I get it in fast enough ;)
The text was updated successfully, but these errors were encountered: