Skip to content
This repository was archived by the owner on Jul 30, 2018. It is now read-only.
This repository was archived by the owner on Jul 30, 2018. It is now read-only.

[User Story] Materializing Data #21

@kitsonk

Description

@kitsonk

User Story

Having a set of data, from a store, query or transformation, a developer will need to materialize this data in a location. This functionality encapsulates the process of introspecting objects in the target store and determining what mutations if any that are required to materialize the data. This also implies an ability to express logic around resolving conflicts.

To contextualise this functionality better, consider a todo application. The developer would have already at this point queried the appropriate business object representations of each todo item and would have applied a transformation to them to change the shape to the appropriate values needed to represent that as a todo item widget state object. Now the developer needs to:

  • Identify which store contains the widget states
  • Express logic on what to do if the identity is not present in the state store, which would include instructing a dojo-app instance to create and register a new widget instance and to append that widget instance to a parent todo item list.
  • Express logic on what to do if an identity is being deleted and any cleanup items
  • Potentially express logic on how to patch an existing widget state

Considerations

There are several key factors that need to be considered around the Materialization API:

  • Results - Unlike the Query and Transformation API, the results of the Materialization API are CRUD operations to be performed against a store.
  • API Functionality - Instead of being feature rich and expressive, like the Query and Transformation, the Materialization API is essentially a set of functions which aid a developer in being able to deal with identifying and encapsulating CRUD operations given a source and destination set of data.
  • Co-dependency - Consideration should be given to how to deal with co-dependency of materialisation. For example, being able to express that both the creation of the a widget state, the creation of a widget instance and adding the widget as a child of a parent must all be successful for the materialisation to be successful.
  • Diagnostics - It is likely, for debugging and development purposes, the ability to get detailed diagnostics of what is occurring during the materialisation would be required.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions