My Gomi Guide: Solving the Four-Bin Problem

I handle all the trash in my household.

We have a poster on our fridge. It explains which bin, which day, how to prepare each item. It’s been there since we moved in, held up by a plain magnet, taking up space I’d rather give to a travel souvenir.

Every few days I’d glance at it before heading to the trash room. Sometimes I’d read the whole thing from the top just to confirm what I already thought I knew.

So I built a tool. The rules are in my phone now. The poster is coming down.

That space on the fridge is going to Japan Rail Pass magnets.

Gomi is not simple

The Japanese word for trash is gomi (ごみ). Japan’s recycling system is thorough and has a learning curve. Minato ward has four regular collection categories, each on a different day, each with its own prep rules.

That fridge poster is bilingual: English and Japanese, with illustrated examples for each category. I photographed it and started cataloguing.

Here’s how the four categories break down:

The poster has the basics. It even shows プラ for recyclable plastics. Here’s what I figured out by actually sorting:

What I built

The dataset covers 50 items across all four categories. Beyond the standard items, it covers the edge cases that matter most.

Search results show a one-line TL;DR, the collection day, and a prep section broken into bullets. The weekly schedule auto-highlights today’s collection.

Before generating a line of code

I framed what “good” meant for this specific tool.

The constraints I was working inside:

Here’s what the system looks like from the outside:

The browser gets code from Vercel’s CDN and data from Blob. A data fix is a file upload. A code change goes through git. Neither requires the other.

How it evolved

It started as a simple list.

Steps 2 through 4 each left a mark.

The Tailwind gotcha that bit me

Tailwind’s JIT compiler scans source files at build time and generates only the CSS classes it finds. JSON fetched at runtime is invisible to it. Move category color strings into that JSON and they get dropped from the compiled CSS entirely. Everything renders unstyled.

{
  "plastics": {
    "badge": "bg-sky-100
              text-sky-700
              dark:bg-sky-900/40"
  }
}

const CATEGORY_STYLES = {
  plastics: {
    badge: "bg-sky-100
            text-sky-700
            dark:bg-sky-900/40"
  }
};

The fix: keep CSS class strings in the component source as a static mapping. Data (item names, keywords, prep instructions, icon paths) lives in the JSON. Styling (badge colors, card backgrounds, borders) lives in a constant the scanner can reach.

One entry per category. Every class string is written out fully so the JIT scanner finds them:

const CATEGORY_STYLES = {
  plastics:       { badge: 'bg-sky-100 text-sky-700 dark:bg-sky-900/40 dark:text-sky-300',           card: 'bg-sky-50/50 dark:bg-sky-950/20',          border: 'border-sky-200 dark:border-sky-800/40',          dayLabel: 'text-sky-600 dark:text-sky-400',       dotColor: 'bg-sky-500 dark:bg-sky-400' },
  resources:      { badge: 'bg-emerald-100 text-emerald-700 dark:bg-emerald-900/40 dark:text-emerald-300', card: 'bg-emerald-50/50 dark:bg-emerald-950/20',    border: 'border-emerald-200 dark:border-emerald-800/40',    dayLabel: 'text-emerald-600 dark:text-emerald-400', dotColor: 'bg-emerald-500 dark:bg-emerald-400' },
  combustible:    { badge: 'bg-orange-100 text-orange-700 dark:bg-orange-900/40 dark:text-orange-300',    card: 'bg-orange-50/50 dark:bg-orange-950/20',       border: 'border-orange-200 dark:border-orange-800/40',       dayLabel: 'text-orange-600 dark:text-orange-400',   dotColor: 'bg-orange-500 dark:bg-orange-400' },
  noncombustible: { badge: 'bg-violet-100 text-violet-700 dark:bg-violet-900/40 dark:text-violet-300',    card: 'bg-violet-50/50 dark:bg-violet-950/20',       border: 'border-violet-200 dark:border-violet-800/40',       dayLabel: 'text-violet-600 dark:text-violet-400',   dotColor: 'bg-violet-500 dark:bg-violet-400' },
};

At runtime, initUI() merges the fetched JSON with CATEGORY_STYLES via Object.assign(). Data from Blob, styles from the component — neither source is complete on its own.

State machine for loading, error, and content

Instead of toggling visibility in ad-hoc places, I built a three-state machine.

Each state owns a DOM element: #gomi-loading for the skeleton, #gomi-error for the error card with a Retry button, #gomi-content for the tool itself. The three state functions toggle visibility on those elements.

The Retry button re-invokes loadData() in place. No page reload needed.

Word-boundary search

Search uses a custom boundary regex, not plain substring matching. Early builds matched “conditioner” to “air conditioner” and “can” to “candle.” The pattern uses (^|[^a-z])..([^a-z]|$) rather than \b, because \b treats the space in a multi-word keyword as a boundary and produces false negatives on phrases. With 50 items the match is fast, but the input is still debounced at 200 ms to avoid firing on every keystroke.

The poster came down

One note: this covers Azabu-Nagasakacho specifically. Pickup days vary by address even within Minato ward. The Minato ward official page is the authoritative source.

The point was to stop re-reading it from the top and take it down.

That spot is going to a magnet from Kyoto. One from Sapporo. One from wherever we go next.

The rules are in my phone now. The space on the fridge is mine.

Open My Gomi Guide →