-
Notifications
You must be signed in to change notification settings - Fork 571
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
Fix grid caching #5200
Fix grid caching #5200
Conversation
WalkthroughThis pull request introduces several modifications across multiple components, primarily focusing on the Changes
Possibly related PRs
Suggested labels
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
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.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (1)
app/packages/spotlight/src/section.ts (1)
451-454
: Consider implementing cleanup for #itemIds SetWhile the tracking logic is correct, the Set will continuously grow as items are only added. Consider implementing a cleanup mechanism when items are no longer needed.
+ // Add to class + cleanup() { + this.#itemIds.clear(); + }Call this method when the section is destroyed or when items are no longer needed.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (6)
app/packages/core/src/components/Grid/Grid.tsx
(2 hunks)app/packages/core/src/components/Grid/useRefreshers.ts
(0 hunks)app/packages/core/src/components/Grid/useSelect.ts
(1 hunks)app/packages/spotlight/src/row.ts
(2 hunks)app/packages/spotlight/src/section.ts
(5 hunks)app/packages/spotlight/src/types.ts
(1 hunks)
💤 Files with no reviewable changes (1)
- app/packages/core/src/components/Grid/useRefreshers.ts
🧰 Additional context used
📓 Path-based instructions (5)
app/packages/spotlight/src/types.ts (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
app/packages/core/src/components/Grid/useSelect.ts (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
app/packages/core/src/components/Grid/Grid.tsx (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
app/packages/spotlight/src/section.ts (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
app/packages/spotlight/src/row.ts (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
🔇 Additional comments (8)
app/packages/core/src/components/Grid/useSelect.ts (2)
19-27
: Improved cache management with retained items tracking
Good implementation of tracking valid items using a Set. The early return when instance is not found helps prevent unnecessary processing.
34-37
: Efficient cleanup of stale cache entries
Good addition of store cleanup logic. This prevents memory leaks by removing entries that are no longer needed.
Let's verify the cache cleanup behavior:
✅ Verification successful
Cache cleanup implementation is correctly implemented
The cleanup logic in useSelect.ts
is properly implemented using an LRU cache (LRUCache from 'lru-cache'). The code maintains a set of active IDs (retained
) and removes entries that are no longer in use, which is the correct pattern for cache cleanup. The implementation is consistent with other cache cleanup patterns found in the codebase, and the use of LRUCache provides additional automatic cache management benefits.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other cache cleanup implementations to ensure consistency
rg -A 3 "store\.delete|cache\.delete" --type typescript
Length of output: 92
Script:
#!/bin/bash
# Check for other cache cleanup implementations to ensure consistency
rg -A 3 "store\.delete|cache\.delete"
Length of output: 2103
Script:
#!/bin/bash
# Let's check the store implementation and usage in the Grid component
ast-grep --pattern 'const store = $$$'
Length of output: 930
Script:
#!/bin/bash
# Let's examine the store implementation in useSelect.ts
cat app/packages/core/src/components/Grid/useSelect.ts
Length of output: 1318
app/packages/spotlight/src/types.ts (1)
41-41
:
Breaking change: Simplified Render type signature
The replacement of soft
and disable
parameters with a single zooming
parameter improves the API's clarity. However, this is a breaking change that requires updates to all implementations of the Render type.
Let's verify all implementations are updated:
✅ Verification successful
The previous pattern was too specific. Let's search more broadly to find render implementations and analyze their usage patterns.
This will help us find the actual implementations using the Render type and verify if there are any usages of the old parameters that need to be updated.
We need to verify the type definition and its usage to understand the impact of this change.
Breaking change is correctly implemented and documented
The type definition shows that the Render
type has been properly updated to use a single zooming
parameter, and looking at the codebase usage in previous search results (particularly in Grid.tsx and DynamicGroupsFlashlightWrapper.tsx), the implementations have already been updated to match this new signature. The change improves the API by:
- Reducing boolean parameters from 2 to 1
- Using more semantic naming with 'zooming'
- Maintaining consistent implementation across the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find all implementations of the Render type
ast-grep --pattern 'render: ($id, $element, $dimensions, $param) => {
$$$
}'
Length of output: 80
Script:
#!/bin/bash
# Let's try a broader search for Render type implementations
rg -l "render.*:" --type ts
# Then look for actual implementations
rg "render.*:" -A 5 --type ts
Length of output: 27689
Script:
#!/bin/bash
# Let's search for implementations that use the Render type from spotlight package
rg -B 2 -A 2 "import.*Render.*from.*spotlight" --type ts
# Also search for any usage of soft/disable parameters in render functions
rg "render.*\(.*soft.*disable.*\)" --type ts
Length of output: 105
Script:
#!/bin/bash
# Let's check the actual type definition and its usage in the spotlight package
cat app/packages/spotlight/src/types.ts
# Search for any files importing from spotlight/types
rg -l "from.*spotlight/.*types" --type ts
Length of output: 1511
app/packages/core/src/components/Grid/Grid.tsx (2)
73-75
: Simplified looker attachment logic
Good simplification of the attachment logic. The direct attachment call improves code readability.
85-87
: Updated fast scrolling condition
The condition for skipping looker creation during fast scrolling is now more semantic with the zooming
parameter.
Let's verify the scrolling behavior implementation:
✅ Verification successful
Fast scrolling optimization verified
The zooming
parameter is correctly implemented as part of a comprehensive scrolling optimization system. The code shows:
- The
zooming
state is managed increateScrollReader.ts
where it's properly toggled based on scroll speed - The Grid component correctly uses this parameter to skip looker creation during fast scrolling
- The implementation is consistent across the codebase with proper handling in both Spotlight and Flashlight packages
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Find other zooming-related implementations
ast-grep --pattern 'if ($condition) {
// $$$scrolling$$$
return
}'
Length of output: 72
Script:
#!/bin/bash
# Let's search for zooming-related code with more context
rg -U "zooming" -A 5 -B 5
Length of output: 26075
app/packages/spotlight/src/row.ts (1)
151-151
: LGTM: Simplified method signature
The parameter changes streamline the visibility handling by removing redundant parameters and introducing a more focused zooming
state.
app/packages/spotlight/src/section.ts (2)
49-49
: LGTM: Added item tracking for deduplication
The #itemIds
Set efficiently tracks unique items, preventing duplicates in the grid.
304-306
: LGTM: Efficient duplicate prevention
The filter ensures each item is processed only once by checking against the #itemIds
Set, improving performance and preventing duplicate renders.
@@ -171,7 +163,7 @@ export default class Row<K, V> { | |||
|
|||
for (const { element, item } of this.#row) { | |||
const width = item.aspectRatio * this.height; | |||
config.render(item.id, element, [width, this.height], soft, hidden); | |||
config.render(item.id, element, [width, this.height], zooming); |
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.
💡 Codebase verification
SpotlightConfig interface needs zooming parameter in render method
The SpotlightConfig interface in app/packages/spotlight/src/types.ts
needs to be updated to include the zooming
parameter in its render method signature, as it's being used in row.ts
.
app/packages/spotlight/src/types.ts
: Add zooming parameter to the render method definition in SpotlightConfig interface
🔗 Analysis chain
Verify render method compatibility
The render method now uses the zooming
parameter. Ensure all implementations of SpotlightConfig.render
handle this parameter correctly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for all render method implementations to verify they handle the zooming parameter
ast-grep --pattern 'render($_, $_, $_, $_) {
$$$
}'
Length of output: 55
Script:
#!/bin/bash
# Search for render method implementations in TypeScript/JavaScript files
rg "render\s*\([^)]*\)" -t ts -t js -A 5
# Also search for SpotlightConfig interface/type definition
rg "SpotlightConfig" -t ts -t js -A 5
Length of output: 16575
@@ -225,7 +218,7 @@ export default class Section<K, V> { | |||
|
|||
updateItems(updater: (id: ID) => void) { | |||
for (const row of this.#shown) row.updateItems(updater); | |||
for (const row of this.#rows) !this.#shown.has(row) && this.#dirty.add(row); | |||
for (const row of this.#rows) !this.#shown.has(row); |
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.
Fix incomplete condition in updateItems method
The current line has no effect as it's just evaluating a condition without using the result. This appears to be a bug.
- for (const row of this.#rows) !this.#shown.has(row);
+ for (const row of this.#rows) {
+ if (!this.#shown.has(row)) {
+ row.updateItems(updater);
+ }
+ }
Committable suggestion skipped: line range outside the PR's diff.
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.
+1 appears that this line has no effect
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.
@tom-vx51, glad we're in agreement.
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.
Noting that this change technically breaks the render
interface used by data lens, but the logic remains unchanged since undefined
will be treated as falsey. I'll take the action item to clean it up.
@@ -225,7 +218,7 @@ export default class Section<K, V> { | |||
|
|||
updateItems(updater: (id: ID) => void) { | |||
for (const row of this.#shown) row.updateItems(updater); | |||
for (const row of this.#rows) !this.#shown.has(row) && this.#dirty.add(row); | |||
for (const row of this.#rows) !this.#shown.has(row); |
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.
+1 appears that this line has no effect
for (const i of rowItems) { | ||
this.#itemIds.add(i.id.description); | ||
} | ||
|
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.
should these be getting removed when the row is destroyed?
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.
yes, good point
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.
Actually, rows are only deleted/destroyed when the section is deleted/destroyed. Will leave a comment
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.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
app/packages/spotlight/src/section.ts (1)
49-49
: LGTM! Good architectural improvement for item trackingThe introduction of
#itemIds
as a Set to track unique items is a clean approach that should help prevent duplicate items and improve performance.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
app/packages/spotlight/src/section.ts
(4 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
app/packages/spotlight/src/section.ts (1)
Pattern **/*.{ts,tsx}
: Review the Typescript and React code for conformity with best practices in React, Recoil, Graphql, and Typescript. Highlight any deviations.
🔇 Additional comments (2)
app/packages/spotlight/src/section.ts (2)
450-453
:
Consider cleanup of tracked items
Items are added to #itemIds
but never removed. This could lead to memory leaks as the set grows indefinitely. Consider clearing or removing specific items when rows are destroyed.
Apply this diff to add cleanup:
destroy(destroyItems = false) {
this.#section.remove();
- for (const row of this.#rows) row.destroy(destroyItems);
+ for (const row of this.#rows) {
+ for (const item of row.items) {
+ this.#itemIds.delete(item.id.description);
+ }
+ row.destroy(destroyItems);
+ }
this.#rows = [];
}
303-305
: Verify the use of id.description for item tracking
While filtering duplicates is good, using id.description
as the unique identifier seems unusual. Should we be using a more direct identifier property?
✅ Verification successful
Using id.description is the correct pattern for item tracking
The usage of id.description
as a unique identifier is consistent throughout the codebase:
- Used for tracking selected items in
useExpandSample
- Used as keys in various stores and maps in Grid components
- Used for item identification in spotlight components
- Used consistently for tracking and deduplication purposes
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other usages of id.description to verify this pattern
rg -A 2 "id\.description" --type ts
Length of output: 3742
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Refactor
show
andRender
methods.Documentation