fix: paginatedTable - calculate visible range on resize

[astandrik]

Closes #2245

Stand

🧠 Detailed Comparison of throttle and rafThrottle

1. Lodash’s throttle (Current Implementation)

🧩 Conceptual Overview:

• Uses a fixed time delay (100ms) to limit execution frequency
• Time-based throttling independent of the browser’s rendering cycle
• Configured to allow both leading and trailing calls

✅ Pros:

• Reliable, well-established library implementation
• Predictable timing with fixed intervals
• Supports explicit cancel() method for cleanup
• Fully configurable (leading/trailing options)

❌ Cons:

• May cause visual jank when updates don't align with screen repaints
• Fixed delay may be suboptimal across different devices
• Less efficient for visual updates needing frame synchronization

---

2. rafThrottle (Available in utils.tsx)

🧩 Conceptual Overview:

• Uses requestAnimationFrame to sync with the browser’s rendering cycle
• Limits execution to once per screen refresh (~60fps on most displays)
• Always executes with the latest arguments

✅ Pros:

• Perfectly aligned with the browser’s repaint cycle
• Automatically adapts to system load and refresh rate
• Minimizes unnecessary calculations between frames
• Uses native browser API – zero external dependencies
• Smoother scroll and animation experiences

❌ Cons:

• Lacks built-in leading/trailing call options like Lodash
• Uses cancelAnimationFrame for cleanup (a slightly different pattern)
• Already present in the codebase, but not used for scrolling yet

---

📊 Comparison Matrix

Criteria	Lodash throttle	rafThrottle
Performance	Good, but fixed timing	Excellent for visual updates
Smoothness	Medium	High
Implementation Complexity	Low (already used)	Low (available, unused)
Adaptability	Fixed interval	Adapts to refresh rate
Bundle Size Impact	Includes Lodash	None (native API)

---

✅ Recommendation

For useScrollBasedChunks, rafThrottle is the better choice, because:

• It syncs DOM updates with the browser's natural rendering cycle
• Results in smoother scrolling, crucial for virtualized tables
• Automatically adapts to different devices and performance levels
• Improves performance on resource-constrained environments
• It’s already defined in the codebase and just needs to be utilized

CI Results

Test Status: ⚠️ FLAKY

📊 Full Report

Total	Passed	Failed	Flaky	Skipped
318	316	0	2	0

😟 No changes in tests. 😕

Bundle Size: ✅

Current: 83.47 MB | Main: 83.47 MB
Diff: +0.30 KB (0.00%)

✅ Bundle size unchanged.

ℹ️ CI Information

• Test recordings for failed tests are available in the full report.
• Bundle size is measured for the entire 'dist' directory.
• 📊 indicates links to detailed reports.
• 🔺 indicates increase, 🔽 decrease, and ✅ no change in bundle size.

[Copilot]

Pull Request Overview

This PR fixes the paginated table’s visible range calculation on window resize by updating the scroll and resize handling logic and adding mock node generation support.

• Introduces a new node generator in nodes.ts to simulate storage nodes.
• Updates getNodes.ts to use the new generator when mock mode is enabled via URL parameters.
• Refactors useScrollBasedChunks.ts to replace lodash throttle with rafThrottle and improve resize handling.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/containers/Storage/StorageNodes/nodes.ts	Adds node generation utilities for simulating storage node data.
src/containers/Storage/StorageNodes/getNodes.ts	Integrates mock node generation using URL parameter flags.
src/components/PaginatedTable/useScrollBasedChunks.ts	Replaces lodash throttle with rafThrottle and updates resize events.

Comments suppressed due to low confidence (1)

src/containers/Storage/StorageNodes/nodes.ts:25

• [nitpick] Consider renaming the callback parameter 'Name' to 'poolName' to improve clarity and avoid potential confusion with types or class names.

poolNames.slice(0, count).map((Name) => ({