-
Notifications
You must be signed in to change notification settings - Fork 672
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
Try adding resultEqualityCheck
to weakMapMemoize
#647
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 8a6eb42:
|
markerikson
changed the title
Add react testing library
Try adding Nov 27, 2023
resultEqualityCheck
to weakMapMemoize
markerikson
force-pushed
the
feature/5.0-computation-comparisons
branch
from
November 28, 2023 03:36
a40329f
to
de5df42
Compare
Cleaned this up some:
|
aryaemami59
reviewed
Nov 29, 2023
src/weakMapMemoize.ts
Outdated
let fnNode = createCacheNode() | ||
const { resultEqualityCheck } = options | ||
|
||
let lastResult: WeakRef<object> | undefined = undefined |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested change
let lastResult: WeakRef<object> | undefined = undefined | |
let lastResult: unknown |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR:
jsdom
InputSelectors
generic arg ofOutputSelector
to be last, because it seemed like it was more ergonomic that way. But then I used it and I'm not sure about that.@internal
prefix from a couple imports because Vitest seemed to be having trouble with this and it doesn't seem to serve any useful purpose'reselect'
in the new.tsx
test file I addedresultsCount()
getter todefaultMemoize
. We currently track recomputations at the selector level, but not how many new results the memoized function returned (because it may have reused existing results ifresultsEqualityCheck
found a match)weakMapMemoize
to try to addresultsEqualityCheck
as an optiontbh I'm really not happy with where this stands. It seems to work, mostly. But we're inherently limited by the way we can't check vs existing cache entries, since we don't have the args lying around. With
defaultMemoize
we have all the existing cache entries in an array.I could imagine writing some code that keeps existing results in a
WeakRef
of some kind (Lenz's suggestion), or traversing the cache nodes tree. But there could be N existing cache entries to compare against, and that's also the behavior that causesdefaultMemoize
with amaxSize > 1
to be kinda slow.So I ended up with a single
lastResult
value for the whole memoized function, and we compare against that. My working assumption is that either you need this to be a cache size of 1 and you want consistent reused results if possible, or you want an infinite cache size and aren't going to be trying to reuse anything.I added a test case with a React todo list. It currently runs a few combos of default vs weakMap, standard vs with
resultsEqualityCheck
, and logs the resulting renders and recomputations to the console. I specifically forcedselectTodoById
to return[todo]
as an array to force a new reference. This wouldn't normally be the case for a straight lookup.Here's my latest results:
I think this says that with
weakMapResultEquality
, the list only re-rendered when we added an item (expected) and not when we toggled completed (good).Concerns
Right now I have no tests. I am also not 100% sure the actual logic is correct.
I'm really feeling uncomfortable about where things stand atm.
I'd still seriously like to make the switch to
weakMapMemoize
as default in Reselect 5.0. But I think it needs to have some form ofresultEqualityCheck
, both to keep API compat with (the relatively few) folks who are doingcreateSelector(a, b, {memoizeOptions: {resultEqualityCheck}})
in the wild, and also because it's a use case thatdefaultMemoize
made handleable in 4.1 and I don't want to regress on that aspect.but what I've got over here is very hacked up and doesn't particularly feel ready.
@aryaemami59 , can you take a look at this and give some thoughts?