This is an Epic issue which originally came out of the identification that the process of mutating application state and business data state was a highly "manual" process in TodoMVC and that we clearly needed a way to express the logic necessary to take business objects and have that populate application state.

At a high level, take this use case for example:

• We have a list of todo items that are persisted somewhere and we need to build an application that allows a user to interact with those items. The items are available as a RESTful collection at /todoitems/.
• We provide an interface to those items via a RESTful dojo-store.
• We then need to query those items that apply to our logged in user from that store.
• We then need to transform the resulting set of items into into several instances of widget state:
  • We need to identify the count of todo items
  • We need to identify the count of completed todo items
  • For each todo item, we need to have a widget state that conforms to the state of a TodoItemWidget and have those states be children of a TodoItemList
• Once we have transformed our data we need to materialise it in the appropriate application state stores so that the dojo-app instance can ensure that the application properly represents the underling business sate.
• When there is a mutation to items in the RESTful collection, we need to reflect those changes throughout the above cycle, so the application reacts to those changes.