google / google/site-kit-wp

Return the user to the hub from bespoke completion handlers

Open
#13,340 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P0 Team M Type: Enhancement
Dominant language
JavaScript
Stars
1.4k
Forks
384
Avg merge
4d 14h
Merged PRs (30d)
77

Description

## Feature Description

#13338 brings the user back to the hub from every setup that finishes through Site Kit's shared module-setup completion. Three flows don't: they finish on a screen of their own and send the user to the dashboard themselves — the Key Metrics step at the end of the refreshed Analytics setup, the Ads PAX flow, and the Ad Blocking Recovery screen.

Left alone, those three are the odd ones out: a user who sets up Analytics, Ads, or ad blocker detection from the hub is dropped on the dashboard while everyone else is returned to the hub to carry on. This issue has each of them look for the record the hub left when it launched the setup and, where there's one, complete to the hub on the tab the user started from instead.

Nothing changes for a user who didn't come from the hub: with no record, each flow completes exactly where it does today.

The Key Metrics questionnaire and Reader Revenue Manager's express route also complete on screens of their own; they're handled with those features' own issues, #13348 and #13345.

For reference, see the [Returning to the hub](https://docs.google.com/document/d/1sLWcimi6eZqbK4YXVCZtO0ZrfrDV7Ub218Hu_vpwmyI/edit?tab=t.0#heading=h.yl5go7548bwn) section in the design doc.

---------------

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

## Acceptance criteria

- Setting up Analytics from the hub and completing the Key Metrics step at the end of its setup returns the user to the hub, on the tab they started from, rather than to the dashboard.
- Setting up Ads from the hub through the PAX flow returns the user to the hub on completion, on the tab they started from, rather than to the dashboard.
- Setting up ad blocker detection from the hub returns the user to the hub when the Ad Blocking Recovery screen's setup completes, on the tab they started from, rather than to the dashboard.
- Where the setup wasn't started from the hub, each of these three flows completes exactly where it does today.
- Nothing else about these flows changes: what they set up, what they show while they run, and how they behave for a user who arrived any other way are all untouched.
- The success confirmation the user sees on returning to the hub is covered by #13356.

## Implementation Brief

- [ ] In `assets/js/components/key-metrics-setup/KeyMetricsSetupApp.js`, in `saveInitialSetup()` (the callback the initial-setup Key Metrics step runs on completion, currently always navigating to `dashboardURL`):
- When `isInitialSetupFlow` is true, call `consumePendingSetup()` (from `@/js/googlesitekit/feature-discovery/pending-setup`, added in #13338) before building the `dashboardURL` notification query args.
- Where it returns a record, read `registry.select( CORE_FEATURE_DISCOVERY ).getFeature( pendingSetup.featureSlug )?.setup?.moduleSlug` and confirm it's `MODULE_SLUG_ANALYTICS_4` — the same match `useFinishSetup` performs for the argument-less flows in #13338, applied here because this step never calls that hook.
- On a match, `navigateTo( getPendingSetupReturnURL( registry.select, pendingSetup.returnTab ) )` and return, skipping the `dashboardURL` navigation.
- On no record, a mismatch, or `isInitialSetupFlow` false (the standalone Key Metrics questionnaire this same screen also serves — that path is #13348's), fall through to today's `dashboardURL` navigation unchanged.
- `saveInitialSetup` is a `useCallback`; resolve `registry` via `useRegistry()` as `useFinishSetup` does, and add it (and `CORE_FEATURE_DISCOVERY`'s selector usage) to the dependency array.

- [ ] In `assets/js/modules/ads/components/setup/SetupMain.js`, in `onCompleteSetup()` (the PAX flow's own completion handler, which builds its own `redirectURL` and calls `finishSetup( redirectURL )` directly — bypassing `useFinishSetup`'s own pending-setup handling from #13338, which only applies to its argument-less branch):
- Before building `redirectURL` from `getAdminURL( 'googlesitekit-dashboard', { notification: PAX_SETUP_SUCCESS_NOTIFICATION } )`, call `consumePendingSetup()` and, where it returns a record, confirm `getFeature( pendingSetup.featureSlug )?.setup?.moduleSlug === MODULE_SLUG_ADS`.
- On a match, build `redirectURL` from `getPendingSetupReturnURL( select, pendingSetup.returnTab )` instead — the existing tracking/survey calls and the `finishSetup( redirectURL )` handoff are unchanged, only the destination differs.
- On no record or a mismatch, keep building `redirectURL` exactly as today.

- [ ] In `assets/js/modules/adsense/components/setup/AdBlockingRecoveryApp/SetupMain.js`, where `setupSuccessURL` is built from `dashboardURL` (the `href` the Complete step's final button navigates to):
- Call `consumePendingSetup()` and, where it returns a record, confirm `pendingSetup.featureSlug` is the catalog's ad-blocking-recovery feature slug — this feature's `setup` descriptor has no `moduleSlug` (it's a `getSetupURL()` target reached only from this screen), so match on the feature slug directly rather than a module.
- On a match, build `setupSuccessURL` from `getPendingSetupReturnURL( select, pendingSetup.returnTab )` instead of `dashboardURL`.
- On no record or a mismatch, keep `setupSuccessURL` built from `dashboardURL` exactly as today.
- The record is consumed destructively, so resolve it once (e.g. alongside the existing `initialActiveStep` resolution, or in a `useMount`/`useEffect`) and hold the resolved return URL (or `null`) in state, rather than re-reading it on every render.

### Test Coverage

- Extend `KeyMetricsSetupApp.test.js` to cover: returning to the hub when `isInitialSetupFlow` is true and the record matches Analytics, and falling through to the dashboard on no record, a mismatch, or `isInitialSetupFlow` false.
- Extend `SetupMain.test.js` (`AdBlockingRecoveryApp`) to cover the Complete step's button `href` pointing at the hub on a matching record and at the dashboard otherwise.

## QA Brief

-

## Changelog entry

-

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the completion handlers in assets/js/components/key-metrics-setup/KeyMetricsSetupApp.js, assets/js/modules/ads/components/setup/SetupMain.js, and assets/js/modules/adsense/components/setup/AdBlockingRecoveryApp/SetupMain.js, then read the pending-setup utilities from #13338. Run the named KeyMetricsSetupApp.test.js and AdBlockingRecoveryApp SetupMain.test.js coverage. Done means matching hub-launched flows return to the originating hub tab while other flows retain their dashboard behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
72/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.