prevent frequent rerenders#895
Conversation
✅ Deploy Preview for livecodes ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Deploying livecodes with
|
| Latest commit: |
43b1f62
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://c257cea8.livecodes.pages.dev |
| Branch Preview URL: | https://prevent-frequent-rerenders.livecodes.pages.dev |
WalkthroughAdds a lastRun state to track the prior iframe run. In the iframe creation/full-page reload path, introduces a time-and-result guard: if a new result matches the previous and occurred within 500 ms, it is treated as already loaded. Updates lastRun timestamp and result whenever issuing a full-page postMessage. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
actor User as User
participant Core as Core (core.ts)
participant Iframe as Preview Iframe
User->>Core: Trigger run (full-page path)
Core->>Core: Compute newResult
alt Guard: recent duplicate (<=500ms) AND result matches lastRun
Note over Core: Treat as already loaded
Core-->>User: Skip reload/postMessage
else Proceed with reload
Core->>Iframe: postMessage(newResult)
Note over Core: Update lastRun = { now, newResult }
Iframe-->>Core: load/ack (async)
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Size Change: -115 B (-0.01%) Total Size: 956 kB ℹ️ View Unchanged
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/livecodes/core.ts (1)
341-344: Effective guard against duplicate renders.The condition properly checks for duplicate results within a 500ms window, preventing unnecessary iframe reloads. The logic is sound:
- Checks are ordered efficiently (no result → local loaded flag → lastRun check)
- String comparison with
===correctly compares result content- Early return prevents the postMessage from firing for duplicates
Consider extracting the 500ms threshold as a named constant for maintainability:
+const RERENDER_DEBOUNCE_MS = 500; + let lastRun = { time: 0, result: '' }; const createIframe = (container: HTMLElement, result = '', service = sandboxService) =>Then use it in the condition:
- if (!result || loaded || (lastRun.result === result && Date.now() - lastRun.time < 500)) { + if (!result || loaded || (lastRun.result === result && Date.now() - lastRun.time < RERENDER_DEBOUNCE_MS)) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/livecodes/core.ts(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (11)
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Redirect rules - livecodes
- GitHub Check: Header rules - livecodes
- GitHub Check: Pages changed - livecodes
- GitHub Check: build (18.x)
- GitHub Check: tests (18.x, 2)
- GitHub Check: tests (18.x, 4)
- GitHub Check: tests (18.x, 5)
- GitHub Check: tests (18.x, 3)
- GitHub Check: tests (18.x, 1)
- GitHub Check: build (18.x)
🔇 Additional comments (2)
src/livecodes/core.ts (2)
264-264: LGTM! Clear initialization for rerender prevention.The
lastRunstate variable is well-initialized with sensible defaults (time: 0 ensures the first run always proceeds). The module-level scope is appropriate for tracking state across multiplecreateIframecalls to prevent rapid successive reloads.
347-347: LGTM! Proper state update after successful message post.The
lastRunupdate is correctly placed after thepostMessagecall, ensuring the state only reflects successful operations. Creating a new object (rather than mutating) is good practice and avoids potential reference issues.



Summary by CodeRabbit
Bug Fixes
Performance & Stability