Shaping/Transforming Data

[kitsonk]

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.

[kitsonk]

Based on a conversation with @maier49 and @agubler here is what I see as the main "use case" for stores and widgets when operating in a Dojo 2 application:

Which the following describes the process:

• Data is present in a business store.
• That data is actively queried
• Then that data is transformed (reshaped)
• Then that data is materialised in two ways:
  • A widget state store, which contains the widget state
  • Managing instances of widgets which are wired to that widget state
• The widgets are wired to actions which mutate the objects in the business store
• Because the data is being actively queried, changes to the business store are reflected in the state of the widgets and their instances managed.

[agubler]

Will the user register a pipeline, .query(), .transform(), .materialize() that gets automatically called on the business store being updated? or will the the user need to include this in a subscription on the store?

[kitsonk]

My feeling was that a pipeline like that would imply that it is being tracked, as that would be the most common use case, with an options to produce it as a one off. I would expect .query() and .transform() to produce observables and .materialize() to return handle. Something like this:

const source = store
    .query({ /* query options */})
    .transform({ /* transform options */);

const target = createMemoryStore();

const handle = materialize({
    source,
    target,
    reducer(item, source, target): ChangeRecord | Promise<ChangeRecord> {
         /* do whatever */
    }
});

handle.destroy();

[dylans]

All dependent issues have been resolved, anything else can be handled via separate issues.