An emerging strength of @lauf/store applications is the ability to define business logic and operations on Store or MessageQueue completely in isolation from the UI code, which simply binds to Stores for data and Queues to dispatch events.
However there are examples where state editors are inlined but
When state editors are used, they should ideally be in a business logic file separate from UI, and at least be segregated from UI code within the file.
Preferably state editors wouldn't be used at all. Instead a Message should be dispatched to a MessageQueue, making the event 'replayable' by a future @lauf/runner although binding a generator around the edit function is an alternative approach for replayability.
An emerging strength of
@lauf/storeapplications is the ability to define business logic and operations on Store or MessageQueue completely in isolation from the UI code, which simply binds to Stores for data and Queues to dispatch events.However there are examples where state editors are inlined but
@lauf/runneralthough binding a generator around the edit function is an alternative approach for replayability.