Lazy JavaScript per route
What a first visit fetches on top of the initial bundle, from the QA build. Before means after step 6. MB means a million bytes.
| Route | Before | After |
|---|---|---|
/edit-preference and its pages | 6.03 MB | 4.33 MB |
/edit-preference/whitelabel-cover-page and its pages | 5.29 MB | 3.18 MB |
/dashboard, still on SharedModule | 5.66 MB | 5.65 MB |
The initial bundle is 4 bytes smaller, and no other entry moved by more than 1 KB. The build has 272 JavaScript files where step 6 had 271.
Commit 56a5ec11eb: make edit preference standalone
What changed
edit-preference.module.tsandedit-preference-routing.module.tsare deleted./edit-preferenceloadsEDIT_PREFERENCE_ROUTESfrom the newedit-preference.routes.ts. The routes, guards and data are the same.- The 48 components the module declared are standalone. Earlier steps had already converted everything they render, so no SharedModule piece had to change.
- The module provided three services.
NgxImageCompressServiceis already provided in root, and the root injector already providesTitleCasePipe.DatePipewas only used by the delegate details page and the transaction detail modal it renders, soDelegateDetailsComponentprovides it now. - The module's
CUSTOM_ELEMENTS_SCHEMAhid a[socialHandles]binding on the social links modal in the link in bio editor. The modal has no such input and loads the handles itself, so I removed the binding. - Three components lose the phone directive. Their templates have no phone input.
- The whitelabel cover page under
/edit-preferencestill loaded its own module in this commit.
How I checked it
| Check | Result |
|---|---|
| Compiled template dependencies against step 6 | 647 of 650 components match. The other three lose only the phone directive. |
| QA and development builds | Both pass. QA has the same 42 warnings as base. Development has none. |
| Server rendering, 138 URLs | All match step 6. The list now has 41 edit preference paths, including guarded, redirected and unknown ones. |
| Logged-in browser run, white-label site | 34 edit preference and cover page URLs. Same components and no page errors. Pages that were still loading after 6 seconds were run again with a longer wait, and then matched. |
| Interactions | The social links modal opens with the same three saved handles. On the white-label appearance form, opening a second color picker closes the first, on both builds. |
| Every component on the entry resolves in the browser | 286 components on edit preference, and 273 on the cover page it loads. No problems and no page errors. |
| ESLint on the changed files | 4 errors, down from 52. The 48 gone are prefer-standalone. The four left exist on base. |
The test account has no delegates, so the delegate details page, the one that needs DatePipe, wasn't opened in a browser.
Commit e92a285200: make the whitelabel cover page standalone
What changed
whitelabel-cover-page.module.tsand its routing module are deleted. The cover page loadsWHITELABEL_COVER_PAGE_ROUTESfrom the newwhitelabel-cover-page.routes.ts, with the same four routes.- The 25 components the module declared are standalone.
- They needed two SharedModule pieces,
VipOfferShareModalComponentandScrollContainerLoaderDirective. Both are standalone now. They moved from SharedModule's declarations to its imports, so SharedModule still exports them. It has 45 declarations left. - The add section page renders 53 of
MarketingPageSharedModule's 57 pieces, so it imports the module, as the marketing pages do. - Three components lose the phone directive. Their templates have no phone input.
How I checked it
| Check | Result |
|---|---|
| Compiled template dependencies against the edit preference commit | 647 of 650 components match. The other three lose only the phone directive. |
| QA and development builds | Both pass with the same warnings as before. |
| Server rendering, 138 URLs | All match the edit preference commit. |
| Every layout in the add section modal | All 47 open the section editor with the same components on both builds, and no page errors. Scrolling the featured creator picker behaves the same. |
| Other cover page actions | Editing the header and the footer, the preview and the add sub-page button land on the same pages. The VIP deals picker opens with the same content. The test account has no VIP deals, so it shows the empty state. |
| Every component on 3 entries resolves in the browser | The cover page, edit preference and dashboard. No problems and no page errors. |
| ESLint on the changed files | No errors, down from 27. All were prefer-standalone. |
Verification checklist
Use a creator account on its white-label site. Keep the console open. Checks that end in save change real data, so use a test account. Checks are saved in this browser.
0 of 0 checked