Extract core module setup component into composable primitives

[nfmohit]

Feature Description

The current assets/js/components/setup/ModuleSetup.js hard-codes the entire setup screen, i.e., the header, progress indicator, content wrapper, intro title, the module's SetupComponent, and footer, and already carries module-specific conditionals for the Analytics initial-setup flow.

The planned upcoming work for Reader Revenue Manager Express Setup is set to add further complexity and module-specific logic to this component, which is not intended.

Instead, this component should be decomposed into smaller, independently composable components under assets/js/components/setup/, for example:

1. SetupHeader: Wraps Header with the optional ExitSetup action and HelpMenu.
2. SetupProgress: Manages the ProgressIndicator.
3. SetupContent: Handles the Grid/Row/Cell wrapper, optional intro title, and content slot.
4. SetupFooter: Reuses the existing ModuleSetupFooter for cancel and complete setup actions.

The intention behind this is for a module to optionally own its entire setup screen when required, and when it does, it can import any of the above primitives to retain the default behavior for areas that do not require customization.

#12975 extracts shared behavior currently inlined in ModuleSetup, i.e., the finishSetup routine (cache clear, event tracking, redirect) and view tracking into custom hooks (e.g., useFinishSetup, useModuleSetupTracking). This allows module-specific screens to reuse core logic without duplication.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The default module setup screen is built from independently composable UI primitives under assets/js/components/setup/, rather than being hard-coded as one monolithic layout in ModuleSetup.
• The following areas of the default module setup screen each have a dedicated, reusable component that preserves current rendering and behavior:
  • Header: Site Kit header with the help menu.
  • Content: layout wrapper, optional “Connect Service” intro title, and a slot for the module’s SetupComponent.
  • Footer: cancel and complete setup actions via the existing footer component.
• Initial-setup-flow UI remains in core temporarily and is relocated to Analytics in Remove Analytics-specific quirks out of the core module setup component #12976.
• Module registration supports an optional ModuleSetupComponent field (alongside the existing SetupComponent).
• ModuleSetup becomes a thin wrapper that renders the module’s ModuleSetupComponent when present; otherwise, it falls back to a default module setup component that composes the shared primitives and reproduces today’s default module setup screen.
• Modules that do not provide ModuleSetupComponent continue to use the default setup screen with no change in behavior.
• A module that needs to own its setup screen can register ModuleSetupComponent and compose the shared primitives where they apply, adding module-specific UI (e.g., progress, exit action) only where needed.
• Existing module setup UI and behavior are unchanged for both standard and initial-setup-flow paths.

Implementation Brief

• Create composable setup primitives under assets/js/components/setup/ for the default module setup flow only:
  • SetupHeader: Wraps Header.
  • SetupContent: Handles the Grid/Row/Cell wrapper, optional intro title, and a content slot for the module’s SetupComponent.
  • SetupFooter: Wraps the existing ModuleSetupFooter for cancel and complete setup actions.
• Create DefaultModuleSetup under assets/js/components/setup/ that composes the primitives above and reproduces the current default module setup layout. It should accept moduleSlug, resolve the module’s SetupComponent, and use the shared setup hooks from Extract common functionalities in module setup component into custom hooks #12975 for finish-setup and tracking behavior.
• Add optional ModuleSetupComponent support to module registration in assets/js/googlesitekit/modules/datastore/modules.js:
  • Add ModuleSetupComponent: null to moduleDefaults.
  • Accept ModuleSetupComponent in registerModule settings and persist it on the module definition (same pattern as SetupComponent).
• Refactor ModuleSetup to delegate to the module-specific or default setup screen:

  const Screen = module?.ModuleSetupComponent || DefaultModuleSetup;  
  return <Screen moduleSlug={ moduleSlug } />;  
  

• Keep Analytics initial-setup-flow conditionals (progress indicator, exit setup, intro/footer visibility, initial-setup layout/classes) within these core primitives for this issue; Remove Analytics-specific quirks out of the core module setup component #12976 relocates them into an Analytics ModuleSetupComponent.
• Export the primitives and DefaultModuleSetup from a stable import path so module-specific setup screens (e.g., Analytics in Remove Analytics-specific quirks out of the core module setup component #12976) can reuse them where applicable.

Test Coverage

• Add component tests for each primitive (SetupHeader, SetupContent, SetupFooter) covering their main render paths and optional props.
• Add tests for DefaultModuleSetup covering the standard module setup flow (header, intro title, SetupComponent, footer).
• Add tests for ModuleSetup verifying it renders ModuleSetupComponent when registered, and falls back to DefaultModuleSetup when not.
• Add or update registerModule tests for the new ModuleSetupComponent field.
• Keep existing ModuleSetup.test.js coverage passing for the standard module setup flow; adjust only where assertions move to DefaultModuleSetup or primitive-level tests.
• Initial-setup-flow test cases remain in ModuleSetup.test.js for now; Remove Analytics-specific quirks out of the core module setup component #12976 moves them to Analytics module setup tests.

QA Brief

Changelog entry