# `PhoenixKitManufacturing.Web.MachinesLive`
[🔗](https://github.com/BeamLabEU/phoenix_kit_manufacturing/blob/0.4.1/lib/phoenix_kit_manufacturing/web/machines_live.ex#L1)

Landing page for the Machines reference book.

Handles four actions, dispatched by `live_action`:

  * `:index` — list of machines, backed by
    `PhoenixKitManufacturing.ColumnConfig.Machines` for configurable
    columns, per-column filters, sorting, and a saved view (persisted via
    `PhoenixKitManufacturing.ViewConfigs`). See `Web.ColumnManagement`.
  * `:types` / `:operations` / `:defect_reasons` — redirect-only, as of
    the entities migration (`dev_docs/ENTITIES_MIGRATION_SPEC.md`).
    `machine_type`/`operation`/`defect_reason` CRUD now lives on the
    generic entities admin UI, so `handle_params/3` immediately
    `push_navigate`s to the matching `/admin/entities/:slug/data` page
    (`Paths.types/0` / `.operations/0` / `.defect_reasons/0`) instead of
    rendering a list of its own — see `handle_params/3`'s redirect clause.

Admin-chrome pattern: self-wrapping render with `LayoutWrapper.app_layout`
so the active subtab's name/description land in the global admin header
(`page_title`/`page_subtitle`, see the `:self_wrapped_layout` on_mount and
`tab_title/1` / `tab_subtitle/1`) instead of an in-page header. The
Machines / Types / Operations / Defect Reasons switcher is a local
`tabs tabs-border` bar rendered under that header — same look as
`PhoenixKitWarehouse.Web.Components.WarehouseHeader` — in addition to
(not instead of) the PhoenixKit admin sidebar's own subtab nav
(`:manufacturing_machines` / `:manufacturing_types` /
`:manufacturing_operations` / `:manufacturing_defect_reasons`), same
dual-nav shape every other module's parent/subtab pair uses.

## Filtering UI

Unlike `PhoenixKitWarehouse`'s list pages, `:index` does not render a
`FilterChips`-style pill widget per active filter — deliberately, to keep
this wave's footprint small (`dev_docs/IMPLEMENTATION_PLAN.md` M17).
Toggling a column's funnel icon in the Columns modal still reveals a
plain labeled input for that column (driven by the very same
`set_filter_value`/`clear_filter` events `Web.ColumnManagement` injects),
but instead of per-chip pill styling with an individual ✕ button, a
single "N filters active" indicator plus one "Reset" button clears every
filter value at once.

## Type-badge staleness window

The `handle_info/2` clauses below that refresh `:machines` on a
`machine_type` broadcast race `EntitiesRegistry`'s own subscription to
the same PubSub message: both processes receive the broadcast
independently, with no ordering guarantee that the registry's ETS cache
has already been invalidated by the time this LiveView's `handle_info/2`
runs `assign_machines/1` and re-resolves `type_names` via
`EntitiesRegistry.label/3`. If this process's callback wins the race, the
re-render can briefly show the pre-change label/title until the *next*
broadcast or navigation. This is accepted as the cost of the pattern —
the same trade-off Andi's `StatusRegistry`-backed live views make — not a
bug to fix here. Deliberately **not** mitigated by making this callback
synchronously reload the registry itself: that would couple this
LiveView to `EntitiesRegistry`'s internals and reintroduce the N+1 query
cost the cache exists to avoid.

# `on_mount`

---

*Consult [api-reference.md](api-reference.md) for complete listing*