Repository navigation
[Feature]: Build functionality into GovernanceWidget #75
Description
Short description of the new GoodWidget
We have build so far the governance components UI. but no functionality behind them.
This task is for extending the governance widget and integrate the actual functionality for it.
That involves:
- wiring in functionality to call the governance smart-contract
- Combining the different components into one 'app-like' widget. The onboarding is build as a flow. dashboard components are decoupled components. both onboarding and dashboard are separated at the moment.
- adding support for connecting wallet and interacting with the widget
- adding interactive stories to test the components and onboarding flow with.
Any core logic, interaction with smart-contract, data fetching should be part of modularized hooks and utils in the governance-widget package but separate folder: sdks
Which repos and packages the AI should work with
-
The Governance widget locally in the goodwidget repository. UI wise and styling the components should not change but if additional props are needed to support functionality, thats fine.
Keep in mind to decouble state and sdk/core logic outside of render UI components. -
The new proposed governance contract: Implement GoodDaoHouses MVP smart contract build GoodProtocol#299
for context you can read up on the issue and subissues for it:
[Feature]: GoodDAO MVP Governance Contract GoodProtocol#297
[Plan]: GoodDaoHouses MVP implementation outline GoodProtocol#298 -
For context around the UI components you can read up on:
[Feature]: Governance homepage components #46
[Feature]: Governance UI Onboarding components #55
and their related sub-issues and pull-requests.
UI implementation reference
The dashboard overview and a header with title and connect button:
This combines the following components (in order):
- Impact card
- two balance cards (flex:row)
- Active governance section with for now only showing 'Alignment Voting'
- Funding distribution
The onboarding flow that is explained below in User flows, can be mostly used as is with just adding the actual functionality.
If unsure where data should come from or how to wire it together please note it down as open questions in the planning task.
User flows, states and behaviours
When no wallet is connected:
- Should be able to freely scroll and look over the different components (and interact with them where possible, open new page etc)
When wallet is connected:
- shows loading spinner
- checks if someone is already a member of house of alignment or house of citizen
- if the answer is no > it should trigger and load the onboarding flow
- if the answer is yes to one of them > it should reload the dashboard and add a footer-bar that includes member details like 'date joined'
Create the plan (keep this section in the issue body)
Create the plan
Based on the above description create an execution plan in a new sub-issue and preserve the original issue content unchanged.
Do not execute the plan until given instructions to do so.
Sub-issue requirements:
- Title format:
[DRAFT][PLAN] <what issue is being planned> - Type:
Task - Description must start with:
<sub-issue title> - Link the sub-issue back to this parent issue.
Instructions when creating the plan:
- Map relevant files that are too be used as reference from all repos mentioned
- import existing @GoodDollar packages
- Map new components that should be created. Assess when a new component should be created in the new savings widget package or made part of the reusable packages/ui
Plan specification required sections:
- Required states, flows, and behaviors
- Execution plan
- acceptance criteria
- human-reviewer checklist
Activity
Godbrand0 commentedon Jul 17, 2026
Application and approach description for “[Feature]: Build functionality into GovernanceWidget” (and related plan / bounty work)
I would treat this as the natural next step after the presentational dashboard (#46 / #50 / #54) and onboarding UI (#55 / #56 / #57 / #58 / #59–#60) work already landed in @goodwidget/governance-widget. The UI surfaces, PageWizard / Stepper primitives, Storybook stories, and Playwright smoke coverage exist; the missing piece is the runtime layer that turns the widget into a real app-like experience against the GoodDaoHouses MVP contract.
High-level approach
• All UI components stay presentational.
• New core logic, contract reads/writes, membership checks, and data fetching live in a new sdks/ (or sdk/) folder inside packages/governance-widget.
• Hooks and pure utils are exported from that folder and consumed by thin container components / the top-level GovernanceWidget.
• Re-use @goodwidget/core (useWallet, provider normalization, host detection) and existing @goodwidget/ui primitives. Import any needed @gooddollar/* packages (ABIs, addresses, existing helpers) rather than re-implementing them.
• Governance-widget package: packages/governance-widget/src/* (ImpactCard, BalanceCard, AlignmentVoting section, FundingDistribution, onboarding tree, GovernanceWidgetProvider, stories, tests).
• Core: @goodwidget/core wallet hooks and provider context.
• UI: PageWizard, Stepper, MiniAppShell, theming.
• Contract side: GoodProtocol#297 / #298 / #299 (GoodDaoHouses MVP) – membership of House of Alignment / House of Citizenship, join/stake flows, profile metadata, date-joined, etc.
• Existing patterns from other widgets (claim-widget, staking-migration-widget, goodreserve-widget) for wallet connection, loading states, transaction steppers, and story-driven testing.
• Any existing GoodDollar SDKs or ABI packages that already expose governance / identity helpers.
• No wallet connected Dashboard and all presentational components remain fully scrollable and interactive (open detail views, etc.). Connect button is visible in the header.
• Wallet connects Show loading spinner. Call membership check (isMember of House of Alignment or House of Citizenship).
• Not a member → automatically enter the existing onboarding flow (welcome → identity → house selection → profile → stake/tx progress → success).
• Already a member of either house → stay on / reload the dashboard and surface a footer bar with member details (at minimum date joined; house membership badge if useful).
• Onboarding flow keeps its current UI; only the action handlers, validation that needs on-chain data, stake amount, identity status, and final success CTAs become live.
• Dashboard data (impact numbers, balances, active governance “Alignment Voting”, funding distribution) is fed from hooks that can start with mocked / placeholder values and progressively switch to real contract / indexer reads.
• All error, pending, and retry states for transactions follow the existing Stepper patterns already used in onboarding and other widgets.
• Light/dark theme and responsive behaviour remain unchanged.
• Confirm exact GoodDaoHouses ABI, addresses (testnets / production), and the minimal set of view/write methods needed for membership check, join, stake, and profile.
• Create packages/governance-widget/src/sdks/ (or sdk/) with clear sub-folders: contracts/, hooks/, utils/, types/.
• Add TypeScript types that mirror the contract input shape already referenced by the onboarding profile forms. Phase 1 – Wallet + membership gate
• Wire useWallet from @goodwidget/core.
• Implement useGovernanceMembership (or equivalent) that returns { isConnected, isLoading, isMember, house, joinedAt, … }.
• Top-level GovernanceWidget (or a new thin App shell) decides:
• disconnected → pure dashboard
• connected + loading → spinner
• connected + !member → Onboarding flow
• connected + member → Dashboard + footer.
• Keep the decision logic outside any presentational component. Phase 2 – Onboarding live actions
• Map each onboarding step’s “Continue / Stake / Confirm” to the corresponding contract call(s) via the new SDK hooks.
• Identity verification status should come from the existing GoodDollar identity / whitelist surface if available, otherwise a clear open question is recorded.
• Stake amount and any required approvals use the same Stepper UI already present.
• On successful join, transition cleanly to the member dashboard + footer. Phase 3 – Dashboard data + footer
• Replace static props on ImpactCard, BalanceCards, Alignment Voting section and FundingDistribution with data from modular hooks.
• Footer component (new, small, widget-local) shows joined date and basic member info; keep it decoupled so it can later grow. Phase 4 – Interactive stories & tests
• Extend Storybook with interactive stories that mock the SDK layer (connected / not-member / member / loading / error / success paths).
• Update Playwright widget tests to cover the full connect → membership decision → onboarding or dashboard+footer paths.
• Keep visual regression screenshots stable; only add new ones for the footer and loading states. Phase 5 – Polish & open questions
• Document any data sources that are still unclear (e.g. exact impact / funding numbers, indexer vs pure contract reads, multi-house membership edge cases).
• Ensure tree-shaking, package exports, and theming continue to work for both React and Web-Component consumers.
• Disconnected state shows the full scrollable dashboard with working connect button.
• Connect triggers loading → correct branch (onboarding or dashboard + footer).
• Onboarding can complete a real (or realistically mocked) join/stake flow against GoodDaoHouses and lands the user on the member dashboard.
• Member footer displays at least the join date.
• All contract interaction, membership logic and data fetching live in sdks/ hooks/utils; UI components remain pure.
• Existing visual design, theming and component APIs are preserved (new props only where needed).
• Storybook interactive stories + Playwright coverage exist for the new flows.
• Package builds, type-checks and existing tests continue to pass.
• No business logic inside presentational components.
• New code lives under governance-widget/src/sdks/.
• Wallet connection re-uses @goodwidget/core.
• Membership gate matches the stated user flows exactly.
• Onboarding still looks and behaves like the already-approved UI.
• Footer is minimal and non-intrusive.
• Stories and Playwright tests cover the three main states (disconnected / onboarding / member).
• Open questions (data sources, multi-house, identity source, etc.) are explicitly listed.
• PR targets the correct base branch and links back to the parent feature + plan issues
L03TJ3 commentedon Jul 17, 2026
Hey @Godbrand0 Most of the structure of goodbounties is: [Feature] > [Plan] > [GoodBounties]
You can see the sub-issues and this one is already assigned.
More bounties next week