PR 10829 review-astra

Review verdict

No actionable regression found in the reviewed changes. The conversion preserves the lazy entry points, required template imports, route guards, and pro-page slug lookup. The QA build passed, and the server-rendered route checks matched the outcomes reported in the PR.

This is a code-review conclusion with limited runtime coverage. Browser interactions, generated white-label projects, and pro pages with freshly fetched content still need verification.

What changed

• /advertise now loads AdvertisementHomeComponent directly with loadComponent. Its empty-path routing module and feature module were removed.
• /global still uses loadChildren, now importing GLOBAL_ROUTES. The category-creator-listing child remains intact.
• Generated pro-page routes load MarketingProPageComponent directly. The prefetch generator was updated along with the checked-in routes, so regeneration retains the new route shape.

The three components remove standalone: false and declare their template dependencies in imports. The repository uses Angular 21, where standalone is the default.

Checks behind the verdict

Template dependencies remain available

The advertisement template uses common directives, shared image directives, the circle icon, FAQ, and button components. Its new imports provide those dependencies. The category-listing template is covered by CommonModule and SharedModule. The pro-page preview and contact-form components remain exported by MarketingPageSharedModule, and FAQ is imported directly.

Removing CUSTOM_ELEMENTS_SCHEMA from the old pro module does not expose a template error in the QA build. No references to the three deleted feature modules remain under src or scripts.

Sources: advertisement imports, category imports, pro imports.

Routes and guards keep their intended structure

The advertise route retains marketingSurfaceGuards. Pro routes still pass through withWhitelabelGuard and the existing case-insensitive matcher. The global route file is dynamically imported, so its static component import stays behind the lazy route boundary.

The pro component checks its own route data before walking up parent routes. Removing the empty-path child therefore still lets it read marketingProSlug. No change to slug resolution is needed.

Sources: application routes, global child route, slug resolution.

Regeneration keeps the conversion

A focused check executed the actual normalization and route-serialization functions from the PR using pro, refer, and two nested apps/* slugs. All four leaf routes emitted loadComponent, preserved their full slug data, and retained the apps parent. No deleted module reference or loadChildren appeared in the generated result.

Source: route generator.

Validation performed for this review

The exact PR head was checked in an isolated checkout with the existing installed dependencies. Generated content was not refreshed, and the working application's local changes were not used.

• QA build passed using ng build --configuration=qa --prerender=false with the required 10 GB Node heap.
• Initial bundle was 12.30 MB. The build emitted a 10 MB budget warning, CommonJS warnings, and CSS selector warnings. The PR author also reports 12.30 MB for the base build; this review did not rebuild the base.
• Generator assertions passed for top-level and nested routes.
• Diff whitespace check passed.

A component tag in server output confirms that the route can render its component. It does not establish that browser-only content, search, scrolling, or form submission works. The category template itself is gated by cs.isBrowser.

Existing data mismatch, not a new finding

The committed pro-route file contains two apps/* slugs, but the data file contains only apps/music-band-fan-club. The requested pages have no matching content, so the component redirects to not-found. Neither /pro nor /refer appears in this committed generated route snapshot.

The base has the same slug mismatch, and this PR does not change the data file. This is therefore excluded from the PR's regression findings. Standard QA, staging, and production build scripts run prefetch first; a direct CLI build, as used here, does not.

The PR author reports a separate prefetch and rebuild that rendered six pro routes successfully. That result is author-reported, not independently repeated in this review. The local generator assertions verify serialization, not live API content or a refreshed deployment.

Sources: committed routes, committed content, build scripts.

Remaining checks before release

• Open /advertise in a browser. Check the registration buttons, category navigation, and FAQ expansion.
• Enter the creator listing through a category link so the shared category state is populated. Verify filtering, pagination on scroll, and back navigation.
• After prefetch, open /pro, /refer, and a published nested app page. Check content, FAQ, contact-form submission, and navigation between pages.
• Build a generated white-label project and confirm the existing marketing redirects. Exercise the logged-out PWA redirect separately. Only the main TopFans project was available in this reviewed checkout.

No application source changes or GitHub review comments were made as part of this review.