Shopping Workflow

A list is a shared state machine

ShoppyCat treats a shopping list as living household state rather than a static checklist. Items carry quantity, unit, category, checked state, contributor identity, and price hints. Personal, directly shared, and household lists arrive as reactive streams and are merged without duplicating the same list.

A check action updates the interface immediately, then commits through a Firestore transaction. If the remote operation fails, the visible state returns to its previous value and explains the error. Deletes and clear-checked actions remain undoable before they are flushed.

Designed for the aisle

Quick Add accepts comma, semicolon, or line-separated groceries
Quantities understand decimals, slash fractions, and Unicode fractions
Known units separate from item names without requiring a rigid form
Categories can follow a store order chosen by the household
Active and checked filters support both planning and focused shopping
Contributor identity stays visible on collaborative lists
Community price hints assist without pretending to be guaranteed prices

Parse useful intent, preserve review

The working Android parser handles more forms, but the policy is compact: recognize an optional quantity, recognize a known unit only when it is actually present, and leave the remaining words intact as the item name. Ambiguous text remains editable instead of being silently rewritten.

ArcoBASICArcoBASIC communication example: interpret one Quick Add entry

' Turn a short grocery phrase into structured list data.
FUNCTION ParseQuickAdd(text)
    words = String.Split(String.Trim(text), " ")
    quantity = 1
    unit = ""
    nameStart = 0

    ' A leading number expresses quantity when one is present.
    possibleQuantity = NUMBER(words[0])
    IF possibleQuantity > 0 THEN
        quantity = possibleQuantity
        nameStart = 1
    END IF

    ' Only recognized measurement words become units.
    knownUnits = ["kg", "g", "lb", "oz", "cup", "can", "pack"]
    IF nameStart < Array.Length(words) AND Array.Contains(knownUnits, Lower(words[nameStart])) THEN
        unit = words[nameStart]
        nameStart = nameStart + 1
    END IF

    ' Everything else remains the human-readable item name.
    nameParts = []
    i = nameStart
    WHILE i < Array.Length(words)
        Array.Push(nameParts, words[i])
        i = i + 1
    WEND

    RETURN {"Name": String.Join(nameParts, " "), "Quantity": quantity, "Unit": unit}
END FUNCTION

item = ParseQuickAdd("2 kg potatoes")
PRINT item.Name
PRINT item.Quantity

Optimism with a way back

Fast interaction matters in a store, but speed is not permission to lie. ShoppyCat keeps the original list behind pending destructive mutations, overlays the proposed state while the undo window is open, and reconciles that state with later snapshots.

This makes responsiveness and honesty compatible. The interface can feel immediate while still acknowledging that a networked write may fail or that another household member may change the same list.

The pattern behind the parser, not the parser

The Quick Add grammar, the transaction rollback, and the undo window before a destructive flush are ShoppyCat specifics. A different project will parse different input, commit through a different backend, and undo different actions. What is worth taking away is the discipline underneath them, not the code that implements it here.

The same three ideas show up anywhere a system takes user input under uncertainty: form validation that preserves the original text on failure, text editors with undo history, collaborative documents merging concurrent edits, even a shopping cart that reconciles inventory at checkout. The mechanism changes; the obligation to stay honest about what has and has not been committed does not.

Quick Add only classifies the parts of an entry it can classify with confidence, a leading number as quantity, a recognized word as a unit, and leaves everything else as the item name rather than forcing a rigid grammar. Any input parser can borrow that restraint: classify what you can prove and leave the rest legible instead of silently mangled.
The check action updates the interface immediately and only reverts if the underlying transaction actually fails. That is optimistic UI done honestly: move fast, but keep the last known-good state on hand so a failure has somewhere real to land.
Deletes and clear-checked stay reversible before they flush to the server. Any interface with a destructive action can borrow that grace period instead of relying on a single confirmation dialog people click through without reading.
Personal, shared, and household lists merge into one stream without duplicating the same list twice. Deduplication belongs at the point where sources combine, not scattered downstream as a patch on every consumer.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Reactive stream: A continuing sequence of values that updates subscribers when state changes. ShoppyCat uses streams so lists, pantry items, recipes, and household data can update the interface without manual refreshes.
Transaction: A read-and-write operation that succeeds against one consistent version of the data or retries when another change happened first. It prevents a stale edit from silently replacing newer state.
Optimistic update: Updating the interface immediately before a remote write finishes, then confirming or reverting the change. It makes interaction fast while retaining a recovery path when persistence fails.