Lazy-load the ELK layout engine in the flow builder - #4150
Conversation
The flow builder statically imported elkjs (~1.5MB) at module load through applyAutoLayout, so it was bundled into the builder's entry chunk and parsed on every flow open, even though auto-layout only runs on demand (toolbar action, or opening a flow with no stored node positions). Saved flows carry positions, so the common path never uses it. Dynamically import ELK on first layout instead. The builder entry chunk drops from ~2.4MB to ~1.0MB (727KB to 308KB gzipped), and ELK loads only when a layout is actually requested. Refs thunder-id#3871
📝 WalkthroughWalkthroughELK loading in the auto-layout utility now occurs dynamically and is cached for subsequent layout requests. Layout computation and existing failure fallback behavior remain unchanged. ChangesAuto-layout initialization
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install timed out. The project may have too many dependencies for the sandbox. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@frontend/apps/console/src/features/flows/utils/applyAutoLayout.ts`:
- Around line 58-61: Update getElk so a rejected dynamic-import promise clears
the cached elkPromise before propagating the error, allowing subsequent
auto-layout attempts to retry the import while preserving successful promise
caching.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 0ae82e97-7b59-4385-95cc-9c3b995974f4
📒 Files selected for processing (1)
frontend/apps/console/src/features/flows/utils/applyAutoLayout.ts
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
|
Folded into #4153 (same file, combined as one change) together with the CodeRabbit retry fix for the cached dynamic import. |
1 participant
Purpose
Speed up opening the flow builder. Clicking a flow in the flows list showed a noticeable delay before the canvas appeared.
The builder page is code-split, so opening it downloads and parses a single large chunk before anything but the loading spinner renders.
applyAutoLayoutstatically importedelkjs(the ELK layout engine, ~1.5MB) at module top level, so the entire engine was bundled into the builder's entry chunk and parsed on every open, even though auto-layout only runs on demand (the toolbar action, or opening a flow whose nodes have no stored positions). Saved flows carry node positions, so the common editing path never uses ELK at all.Approach
Dynamically import ELK on first layout and cache the instance, instead of importing it eagerly at module load. The static import becomes type-only. No behavior change:
applyAutoLayoutis already async, so the layout call simply awaits the engine before running.Result (production build of the console app):
ELK now downloads only when a layout is actually requested.
Related Issues
Related PRs
Checklist
applyAutoLayoutsuite, 25 tests, still passing)breaking changelabel added.Security checks
Summary by CodeRabbit