Split-State Account Settings

This example is about ownership boundaries, not fancy form plumbing.

Three sections own different parts of the same account settings store:

• ProfileSection owns email and displayName
• PlanSection owns plan
• TeamSection owns teamSize and teamDomain

Umpire still evaluates cross-cutting rules once, globally:

• teamSize only enables when plan === 'team'
• teamDomain requires teamSize > 0
• email stays required the whole time

Split ownership

Account Settings

one store, one umpire

Each section owns its own slice. `fromStore()` pulls them back together with one `select()` call.

ProfileSection

Owns profile fields

state.profile

Email

enabledrequiredavailable

Display Name

enabledoptionalavailable

PlanSection

Owns billing plan

state.billing

personalteam

This section never touches team inputs directly. It only flips plan and Umpire handles the cross-section availability.

TeamSection

Owns team fields

state.team

Team Size

disabledoptionalteam plan required

Team Domain

enabledoptionalavailable

Global reads

Aggregated Output

select + field()

Condition{ plan: 'personal' }

Anywhere readfield('teamSize') => disabled

Rule 1`teamSize` only enables on the team plan.

Rule 2`teamDomain` requires `teamSize > 0`.

Rule 3`email` stays required regardless of which section owns it.

select(state)InputValues

{
  "email": "alex@example.com",
  "displayName": "Alex Rivera",
  "teamSize": "5",
  "teamDomain": "stadiumops.dev"
}

availabilityfield map

{
  "email": {
    "enabled": true,
    "fair": true,
    "required": true,
    "reason": null,
    "reasons": []
  },
  "displayName": {
    "enabled": true,
    "fair": true,
    "required": false,
    "reason": null,
    "reasons": []
  },
  "teamSize": {
    "enabled": false,
    "fair": true,
    "required": false,
    "reason": "team plan required",
    "reasons": [
      "team plan required"
    ]
  },
  "teamDomain": {
    "enabled": true,
    "fair": true,
    "required": false,
    "reason": null,
    "reasons": []
  }
}

The Pattern

select() is the whole trick:

const umpStore = fromStore(accountUmp, store, {
  select: (state) => ({
    email: state.profile.email,
    displayName: state.profile.displayName,
    teamSize: state.team.size,
    teamDomain: state.team.domain,
  }),
  conditions: (state) => ({
    plan: state.billing.plan,
  }),
})

Each section keeps owning its own slice. Umpire never needs to know that the values came from different components.

What To Notice

1. One fromStore() call sets up the whole app-wide availability layer.
2. requires() still propagates transitively, so disabling teamSize also knocks out teamDomain.
3. Any component can read umpStore.field('teamSize') without mounting its own useUmpire() instance.
4. When the plan flips back to personal, fouls recommend clearing stale team values instead of mutating state automatically.

Which Package To Use

• Use @umpire/store if your store already provides (next, prev).
• Use @umpire/zustand if you want the named Zustand entry point.
• Use @umpire/redux, @umpire/pinia, @umpire/tanstack-store, or @umpire/vuex when those libraries need the thin normalization layer.