Building PocketDex Tracker: A Next.js and Supabase App for Pokemon TCG Pocket Collections

Michelle Wiginton — Sun, 28 Jun 2026 22:04:37 +0000

PocketDex Tracker is a collection tracking app for Pokemon TCG Pocket. It lets players record which cards they own, monitor completion progress by set, search across the card database, and compare packs based on the cards they are still missing.

The app is built with Next.js App Router, React 19, Supabase Auth, Supabase Postgres, row-level security, generated TypeScript database types, Tailwind CSS, shadcn-style UI components, and a small expected-value engine for pack recommendations.

Project Links

Live app: pocketdex-tracker.vercel.app
GitHub repo: mwiginton/pocketdex-tracker

What the App Does

PocketDex Tracker supports the core workflows of managing a digital card collection:

Sign in with email and password.
View overall collection completion.
Drill into individual sets.
Mark cards as owned or missing.
Search cards by name, set, rarity, type, and ownership status.
Compare pack recommendations using missing card pull odds.
Export or import collection data as JSON or CSV.

At a high level, the app combines static card metadata with each user’s private ownership state. That combination powers both progress tracking and pack ranking.

Tech Stack

The frontend uses Next.js App Router with a mix of Server Components and Client Components. Server Components handle authenticated data loading, while Client Components handle interactive ownership toggles and optimistic UI updates.

Supabase provides the backend:

Supabase Auth manages users.
Postgres stores sets, cards, packs, pull odds, and owned-card records.
Row-level security protects per-user collection data.
SQL RPC functions return dashboard aggregates and recommendation rows.
Generated TypeScript types make database access safer.

The interface is styled with Tailwind CSS, shadcn-style primitives, Radix UI components, Lucide icons, and Next Image for card artwork.

Data Model

The database is organized around five main tables:

sets: expansion metadata such as name, release date, card counts, and images.
cards: individual cards, collector numbers, rarity, category, type, and image URLs.
packs: booster packs tied to sets.
card_pack_odds: pull probabilities for each card in each pack.
user_cards: the signed-in user's owned-card state.

Most tables are public read data. The sensitive table is user_cards, where RLS policies ensure users can only read, insert, update, or delete their own rows.

That separation keeps shared card data simple while preserving privacy for user-specific collection state.

Authentication and Sessions

The app uses @supabase/ssr to create separate Supabase clients for server and browser environments.

Protected pages call supabase.auth.getUser() on the server. If there is no authenticated user, the app redirects to /auth/login.

A Next.js proxy refreshes Supabase sessions across requests, allowing Server Components to load user-specific data without moving authentication checks entirely into client code.

Dashboard Data

The home page shows overall completion, owned cards, missing cards, total cards, and progress by set.

Instead of fetching every card and calculating completion in React, the app calls a Postgres RPC function:

const { data, error } = await supabase.rpc("get_home_set_completion_rows");

The UI then derives:

overall completion ratio
per-set completion ratio
closest set to finishing This keeps aggregate work close to the database and lets the page render from compact, purpose-built result rows.

Tracking Cards

Set pages load card metadata on the server and pass it into a client-side CollectionGrid.

The grid manages local state for owned cards, pending saves, errors, and filters. When a user marks a card as owned, the UI updates optimistically and then writes to Supabase:

await supabase
  .from("user_cards")
  .upsert({ user_id: userId, card_id: cardId });

Unmarking a card deletes the matching user_cards row.

The same interaction pattern appears in search results, so users can update their collection from either the set view or the search view.

Search and Filtering

The search page supports filters for:

card name
set
rarity
Pokemon type or trainer category
owned or missing status

Search is implemented with Supabase queries and URL search params, making filtered views reload-safe and easy to share.

For owned-only searches, the app uses an inner join against user_cards. For missing-card searches, it checks for null joined ownership rows.

Pack Recommendations

Pack recommendations are based on the user’s missing cards and the pull probabilities for each pack.
The app asks Supabase for rows containing:

recommendable packs
missing cards
pull probabilities
card metadata The TypeScript recommendation logic groups those rows by pack and calculates expected new cards:

expectedNewCards += pullProbability;

For each pack, the app sums the probability of pulling each missing card. The final list is sorted by expected value, then by pack order and name for stable ranking.

Recommendations can be scoped to the whole collection or to a specific set. The app also supports an option to include unavailable limited-time packs, stored as an HTTP-only cookie.

Import and Export

The settings page gives users a way to back up and move their collection data.

Exports are available as JSON or CSV and include card IDs, ownership dates, and card metadata. Imports accept PocketDex JSON or CSV files, validate card IDs against the database, skip unknown rows, ignore duplicates, and upsert valid owned-card rows in batches.

Testing the Recommendation Logic

The recommendation logic lives in lib/recommendation, separate from the UI. It can be compiled and tested independently with Node’s built-in test runner.

That keeps the expected-value calculation easy to verify: given packs, missing cards, and odds, the same inputs should always produce the same rankings.

Running Locally

To run the app:

npm install
cp .env.example .env.local
npm run dev

Then configure the Supabase URL and publishable key in .env.local.

The database setup lives in the supabase/ directory, including base schema, RLS policies, RPC functions, and seed files for supported Pokemon TCG Pocket sets.

Closing Thoughts

PocketDex Tracker uses server-rendered data where possible, client interactivity where it improves the experience, and database-side logic for aggregation-heavy queries. The result is a compact full-stack app with typed data access, RLS-protected user state, optimistic updates, SQL-backed summaries, portable collection data, and recommendation logic that can be tested independently from the interface.

DEV Community: Michelle Wiginton