-
Notifications
You must be signed in to change notification settings - Fork 20
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
Add throttle
to prevent preview's indiscriminate updates
#391
Conversation
WalkthroughThe changes in this pull request primarily focus on enhancing the Changes
Sequence Diagram(s)sequenceDiagram
participant Editor
participant Preview
Editor->>Preview: Document content changes
Preview->>Preview: Call throttledUpdatePreviewContent
Preview->>Preview: Update preview content (throttled)
Possibly related PRs
Suggested labels
Suggested reviewers
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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
CodeRabbit Configuration File (
|
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: 1
🧹 Outside diff range and nitpick comments (2)
frontend/src/components/editor/Preview.tsx (2)
16-18
: Consider using a more descriptive constant name.
While 500ms is a reasonable throttle delay, consider renaming DELAY
to something more specific like PREVIEW_UPDATE_THROTTLE_MS
to better communicate its purpose.
Line range hint 39-52
: Add cleanup for throttled function and fix useEffect dependencies.
Two improvements are needed in the useEffect implementation:
- The throttled function should be cancelled in the cleanup to prevent potential memory leaks
- The throttled function should be included in the dependency array
Apply these changes:
useEffect(() => {
if (!editorStore.doc) return;
- throttledUpdatePreviewConetent();
+ throttledUpdatePreviewContent();
const unsubsribe = editorStore.doc.subscribe("$.content", () => {
- throttledUpdatePreviewConetent();
+ throttledUpdatePreviewContent();
});
return () => {
unsubsribe();
setContent("");
+ throttledUpdatePreviewContent.cancel();
};
-}, [editorStore.doc]);
+}, [editorStore.doc, throttledUpdatePreviewContent]);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- frontend/src/components/editor/Preview.tsx (2 hunks)
🔇 Additional comments (1)
frontend/src/components/editor/Preview.tsx (1)
Line range hint 18-52
: Verify throttle delay impact on user experience.
The 500ms throttle delay seems reasonable, but we should verify that it doesn't create a noticeable lag in the preview updates, especially for:
- Fast typing scenarios
- Copy-paste operations
- Real-time collaboration updates
Let's check if there are any existing performance-related tests or comments:
✅ Verification successful
500ms throttle delay is within acceptable range for preview updates
The implementation appears to be the only throttled preview update in the codebase, and the 500ms delay is a common and reasonable choice for real-time preview features because:
- It provides a good balance between responsiveness and performance
- The throttle has
trailing: true
which ensures the final state is always rendered - The preview updates are non-blocking and won't affect typing performance
For reference, similar features like VS Code's Markdown preview and GitHub's comment preview also use comparable delays (300-500ms range) for their real-time previews.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for performance-related tests or comments
rg -i "(performance|throttle|delay|lag)" "frontend/src" -g "*.test.*"
Length of output: 69
Script:
#!/bin/bash
# Let's search for any existing usage of throttle or delay in the codebase
# This will help us understand if similar patterns exist and their delay values
rg -i "throttle.*delay|delay.*throttle" frontend/src -A 2 -B 2
Length of output: 64
Script:
#!/bin/bash
# Let's also check for any comments or documentation about preview performance
rg -i "preview.*performance|performance.*preview" frontend/src
Length of output: 64
Script:
#!/bin/bash
# Search for other instances of preview updates or similar real-time preview features
ast-grep --pattern 'const $_ = useCallback(
_.throttle(
$_,
$_,
$_
),
$_
)'
Length of output: 95
Script:
#!/bin/bash
# Let's try a simpler search for throttle usage
rg "throttle" frontend/src -A 2 -B 2
Length of output: 1071
Script:
#!/bin/bash
# Search for any preview-related tests
fd "preview" frontend/src -e test.tsx -e test.ts
Length of output: 48
Script:
#!/bin/bash
# Check if there are any performance-related issues or discussions in the repository
rg -i "preview.*lag|preview.*slow|preview.*performance" --type md
Length of output: 67
Could you please sign the Contributor License Agreement? const throttledUpdatePreviewConetent = useCallback(
// ...
[editorStore]
)
useEffect(() => {
// ...
}, [
// ...
throttledUpdatePreviewContent
]);
|
392edf1
to
db0f772
Compare
@JOOHOJANG I made some changes in this branch to resolve the conflict. Could you sign the CLA? |
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)
frontend/src/components/editor/Preview.tsx (1)
23-23
: Consider making DELAY configurableWhile 500ms is a reasonable default, consider making this value configurable through props or environment variables to accommodate different use cases or performance requirements.
-const DELAY = 500; +const DELAY = process.env.REACT_APP_PREVIEW_DELAY || 500;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
frontend/src/components/editor/Preview.tsx
(3 hunks)
🧰 Additional context used
🪛 GitHub Check: Check the source code (18.x)
frontend/src/components/editor/Preview.tsx
[warning] 66-66:
React Hook useMemo has a missing dependency: 'editorStore.cmView?.state.doc'. Either include it or remove the dependency array
🔇 Additional comments (2)
frontend/src/components/editor/Preview.tsx (2)
20-21
: LGTM: Import changes are appropriate
The addition of lodash for throttling functionality is correctly implemented.
74-84
: LGTM: Effect implementation is correct
The useEffect implementation properly utilizes the throttled function and includes appropriate cleanup.
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.
Thank you for your contribution.
What this PR does / why we need it:
Add
lodash.throttle
to prevent Preview's indiscriminate updates.Which issue(s) this PR fixes:
Address #393
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation:
Checklist:
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Chores