Skip to content

refactor(descriptors): build the shared resource descriptors from fleetops-data - #379

Merged
roncodes merged 1 commit into
release/v0.6.72from
feat/shared-resource-descriptors
Oct 9, 2026
Merged

roncodes merged 1 commit into
release/v0.6.72from
feat/shared-resource-descriptors

Conversation

@roncodes

@roncodes roncodes commented Oct 9, 2026

Copy link
Copy Markdown
Member

What change does this PR introduce?

Companion to fleetbase/fleetops-data#86. The resource identity descriptors for driver, vehicle, customer, contact, place, order, vendor and fleet, their thin pill, summary, identity-cell and select-option wrappers, and the styled placeholder images now live in @fleetbase/fleetops-data, where every extension that lists those resources can use them without loading this engine.

  • utils/resource-descriptors/shared.js (new) takes the shared descriptors and attaches this engine's panelOpener for each key, keeping the order stub guard. people.js, assets.js and operations.js spread those in place of their old inline definitions, so buildFleetOpsResourceDescriptors still returns all 53 and the registry keeps these richer versions over the lazy ones the shared package registers on boot.
  • utils/resource-descriptors/helpers.js re-exports the shared building blocks and keeps panelOpener, routeOpener, parentOpener and colourTile, which only make sense here.
  • utils/placeholder-images.js becomes a re-export so the existing import path, the placeholder-image and resource-image helpers and the trailer placeholder keep working.
  • The 32 wrapper templates and their 32 app re-exports for the eight keys are deleted. They resolve from fleetops-data's app tree now, so <Cell::DriverIdentity>, <Driver::Pill> and friends are unchanged for every template and test that uses them.

Nothing user-facing changes inside FleetOps.

Why was this change needed?

Storefront and other extensions cannot invoke this engine's identity cells, pills or summaries, because an engine's components only exist in its own namespace, and eagerly loading FleetOps from another extension costs the whole bundle. Moving the shared pieces into the package every extension already depends on gives them identical rendering with no engine load until a click. See fleetbase/fleetops-data#86 for the shared side.

Other information

Requires fleetbase/fleetops-data#86 (the local workspace links the package; a published fleetops-data release is needed before this ships).

Validation, run locally against the linked fleetops-data branch:

pnpm exec eslint addon/utils/resource-descriptors addon/utils/placeholder-images.js   # clean
pnpm exec ember test --filter "/resource|placeholder|identity|Pill/"                   # 81 tests, 66 pass, 15 fail

The 15 failures are all pre-existing: the same filter on the untouched release/v0.6.72 fails the same 15 plus two more flaky controller tests. None involves the moved files (they are the generated "it renders" pill stubs asserting empty text, device, telematic, trailer and vendor panel tests). The existing descriptor, wrapper and identity-cell suites pass unchanged, including the "53 descriptors" count and the per-key wrapper rendering test, which now resolves the wrappers through fleetops-data.

No API, postman or fleetbase.io documentation impact beyond what the fleetops-data PR notes.

…etops-data

The driver, vehicle, customer, contact, place, order, vendor and fleet
descriptors, their pill, summary, identity-cell and select-option wrappers,
and the styled placeholder images now come from @fleetbase/fleetops-data, so
every extension that lists those resources renders them the same way without
loading this engine. FleetOps keeps registering all 53 descriptors; for the
eight shared ones it takes the shared descriptor and attaches its own panel
opener, which the registry keeps over the lazy opener the shared package
registers.

The helpers module re-exports the shared building blocks and keeps the
openers that only make sense inside this engine; the placeholder-images
module keeps its import path as a re-export.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant