MagicStarterBillingController class

Backs the billing screen: six independent reads of what a customer is entitled to, what they have spent, and where they manage it.

Why this controller does NOT use MagicStateMixin

Every sibling controller in this package mixes in MagicStateMixin, and this one deliberately does not. That mixin holds ONE T? _state slot and one RxStatus, and both of its transitions null the state: setLoading() calls setState(null, ...) (magic/lib/src/http/magic_controller.dart:177-179) and so does setError() (:195-197). This screen runs six independent reads whose answers have nothing to do with each other, so routing them through one slot would mean any single failing read wipes the other five: an invoices timeout would blank the plan the customer is paying for. Each read therefore publishes its own field and this controller notifies through refreshUI instead.

Every read degrades, none of them throws

A read that fails leaves its own field at last-known state and logs. The screen is a set of independent cards, and a card with no data is recoverable where an exception out of a read takes the whole screen with it. The payment method additionally keeps its OWN pmLoading and pmError, because it is the one read that dials a payment rail live, so a slow or broken rail must gate that card and nothing else.

What the consumer has to supply

usageCopy is REQUIRED, and that is a decision rather than an oversight. Both of the defaults an optional parameter could carry are defects: a pass-through would put the raw wire key requests_this_month on a customer's screen, and a drop would silently remove the usage surface from every app that forgot to pass one. Neither may be reachable by forgetting.

The other two collaborators are optional, and leaving one out is answered in OPPOSITE directions, which is a decision rather than an inconsistency. No MagicStarterTeamOwnershipReader leaves ownership unresolved and every gate permissive, because hiding a purchase button from a real owner stands between them and paying while the server refuses a non-owner regardless. No MagicStarterStoreFundedTeamReader REFUSES the store purchase, because nothing in that build can promise a second purchase will not transfer another team's subscription away, and a customer cannot undo that.

Because it takes required collaborators, this controller is registered with Magic.put(...) rather than resolved through the Magic.findOrPut singleton getter the sibling controllers expose; there is no zero-argument constructor for findOrPut to call.

Example

Magic.put(
  MagicStarterBillingController(
    usageCopy: withUsageCopy,
    storeFundedTeamReader: readStoreFundedTeam,
    isOwnerReader: readTeamOwnership,
  ),
);