seller.setup)
that renders the full seller object as its data. That makes it the perfect
seam for an onboarding checklist: derive completion from the seller you’re
handed, show what’s left, and link each step to the page that completes it — all
from a single widget file, with nothing fetched and nothing forked.
This is the pattern the built-in store-setup card uses. The shipped
“Complete store profile” card is itself a
seller.setup widget that reads the
seller and renders a progress list. This tutorial rebuilds it so you can
shape your own onboarding steps.What you’ll build
A collapsible progress card on the store-setup surface that checks four parts of the seller profile (details, address, company, payment), draws a progress bar, and routes the vendor to the settings page for each incomplete step. When every step is done, the card removes itself.Register the typed targets (once)
Widget zones are typed ids the vendor panel generates from its own pages and ships as@mercurjs/vendor/extension-targets. Reference them once so seller.setup
autocompletes and a wrong zone fails tsc:
apps/vendor/src/extension-targets.d.ts
Build the checklist widget
Derive the steps from the seller
The
data prop is the full SellerDTO. Compute each step’s completed flag
from it — no request needed. Give every step a path to the settings page
that finishes it:apps/vendor/src/widgets/store-setup-checklist.tsx
Render the collapsible progress card
Use
@medusajs/ui primitives and @medusajs/icons only. Draw a progress bar
from the completed ratio, list each step with a status icon, and navigate on
click. Return null when everything is done so the card disappears:apps/vendor/src/widgets/store-setup-checklist.tsx
Where it renders
seller.setup is hosted in two places, both passing the same seller as data:
| Host | When it shows |
|---|---|
| The vendor shell (above the page outlet) | On top-level routes — the dashboard “home” onboarding banner |
| The store settings detail page | Always, above the store status banner |
seller.setup.before / .after
widgets stack in registration order, so your checklist and the built-in card can
coexist — or hide the built-in one by rendering your own and letting theirs
complete.
No data fetching. Because the zone hands you the resolved
seller, the
widget is pure render — you never call the SDK. To collect and persist a new
onboarding value (e.g. a Tax ID) rather than just link to existing pages, see
Extend the onboarding flow, which
carries a value through additional_data to a workflow hook.Next steps
Extend the onboarding flow
Collect a new value and persist it through a workflow hook.
Add a widget
The full widget model and the published zone registry.