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.
Overview
This is a tricky one because I don't know if it 100% works.
Basically the premise is to do two things:
setTimeout
logic out ofuseCoordinates
and move it to theapply
wrapper. Thanks to that, way less time is spent just waiting for the timeout to happen.useAreCoordinatesSelected
hook to mitigate the need to run heavy comparison for every cell click inuseCellIsSelected
. Now it's going to return a boolean and should make things quicker for larger tables.Risks
Point 1. is the risk-prone one. I've experimented with a couple of possible solutions, including using
lodash.debounce
instead ofsetTimeout
, but then I ended up at what's in the PR and it still worked, so I stayed with that. I have not seen it do anything weird but then again, testing npm packages locally isn't an easy task.If we vote against Point 1, Point 2 definitely seems like an easy win, and I'd be happy to cherry-pick just that change.
Testing
See if coordinates stay updated. Monitor the speed of
useCellIsSelected
.