logic-store-type

Decision tree — store implementation

Returns: one of store-entity-async, store-entity-sync, store-simple-async, store-simple-sync.

Precondition: a store is already justified by the application-scoped step of logic-state-layer. If it is not, stop and go back — a store chosen here for state that only needs sharing is the most expensive mistake in this area.

Answer two questions — what shape is the state, and what fills it — and read the variant off this table:

"Collection" means records that are individually addressable: each carries an id and can be updated, removed, or marked pending on its own. An array that is always read and written as a whole counts as one value, so it is simple, not entity.

Collection shape — entity or simple

ASK  are the items individually addressable and independently updatable?

YES -> ENTITY
       a list of bookings, passengers, or search results, where one item can be
       updated, removed, or marked pending on its own
       state extends EntityState<Model> from @ngrx/entity: an adapter, normalized
       ids/entities, generated selectAll/selectEntities/selectIds/selectTotal
       requires an id property (modelIdPropName) — the practical test is that each
       item already carries something that identifies it

NO  -> SIMPLE
       one value, held as a single `model`: the current user session, active search
       criteria, a configuration blob
       also an array always read and written as one unit, such as destination codes.
       There is no meaningful id to key on, and EntityState would force you to invent
       one — holding such an array in a simple store is correct, not a workaround

The distinction matters most for async stores, where entity gives each record its own pending and failure status. A list of strings has nothing to track per item, so that machinery buys nothing.