Week 4 • Mini Capstone Kit Client For Anchor Program
Mini Capstone: Kit Client for an Anchor Program
Ship a full 0-to-1 client slice: connect wallet, read state, submit action, confirm, and verify outcome.
Step 1: 0-to-1 Theory
Primitives
connect: acquire signer capabilityread: fetch current statewrite: submit state changeverify: read-back after confirm
Mental Model
The capstone is one “vertical slice” of a real dApp.
Vertical slice means: one UI path that is fully correct end to end, including failures.
If you can ship one vertical slice cleanly, shipping ten slices becomes mostly repetition.
Invariants
- Every write flow must include post-confirm read-back.
- Every user action must expose status and recovery path.
- Every successful write should return and display signature.
Quick Checks
- Why is read-back mandatory after writes?
- Why should capstone scope stay small?
Step 2: Real-World Implementation (Code Solution)
Build a single page that composes previous lessons.
Create app/week4-capstone/page.tsx:
"use client";
import React from "react";
import { WalletPanel } from "@/components/solana/WalletPanel";
import { AccountInspector } from "@/components/solana/AccountInspector";
import { TxActionCard } from "@/components/solana/TxActionCard";
import { CounterActionButton } from "@/components/solana/CounterActionButton";
export default function Week4CapstonePage() {
return (
<main className="max-w-3xl mx-auto p-6 space-y-6">
<h1 className="text-2xl font-bold">Week 4 Mini Capstone</h1>
<section>
<h2 className="text-lg font-semibold mb-2">1. Wallet</h2>
{/* Connect/disconnect and show explicit wallet status. */}
<WalletPanel />
</section>
<section>
<h2 className="text-lg font-semibold mb-2">2. Read</h2>
{/* Fetch an account by address and show normalized JSON output. */}
<AccountInspector />
</section>
<section>
<h2 className="text-lg font-semibold mb-2">3. Write + Status</h2>
{/* Demonstrate a status machine UX (idle -> confirming -> confirmed/failed). */}
<TxActionCard />
</section>
<section>
<h2 className="text-lg font-semibold mb-2">4. Program Action Service Pattern</h2>
{/* Demonstrate the service-layer pattern for program actions. */}
<CounterActionButton />
</section>
</main>
);
}Deliverables checklist:
- wallet connect/disconnect works
- read panel fetches account data
- transaction status card shows deterministic states
- program action button returns normalized result and signature
Step 3: Mastery Test
- Easy: what single invariant ties all four sections together?
- Medium: where would you place analytics for transaction failures?
- Hard (senior): how would you split this into feature modules for a 6-person team?
If you can explain every state transition and every failure path in this page, you are ready for a larger real dApp client.