Abstraction for working with resources within a dojo application

[agubler]

One of the most common uses of application state or application state store is working with CRUD style resources, managing the status of resource requests, fetching resources, creating resources, updating resources and more. This is currently possible using a solution such as @dojo/framework/stores but requires significant investment on the user to model data, manage statuses, fetch/update/create resources and enabling the application to provide feedback to the user (loading, failed etc).

Proposal

Create a first class API built on @dojo/framework/stores for working with resources throughout a Dojo application. The idea is that the user would not need any intimate knowledge about how the resource data is stored or even that @dojo/framework/stores is being used.

Using the Provider pattern a user would simply factory a new ResourceProvider for a specific resource type and use this as normal within application.

render() {
  return <MyResourceProvider renderer={(myResource) => {
    const result = myResource.getOrRead();
    // do stuff with your resource result.
  }} />;
}

The resource provider should be able to support the complete range of CRUD related scenarios when working with resources:

• Fetching and caching the resource items
• Return resource items from the cache
• Creation of new resource items
• Update existing resource items
• Remove existing resource items
• Support optimistic updates for all operations
• Pagination Support
• Automatically revert changes for failed operations
• Expose statuses of specific operations based on action type i.e. read, create, update and resource identifier
• Management of changes/operations when there are one or more in-flight requests
• Provide customisable Restful configuration for working with remote REST resources
• Reset cached resources when a resource provider is first rendered. This is to ensure that the latest resource data is also rendered when navigating through an application

[agubler]

Another alternative to the Provider(renderer prop) pattern would be use the this.meta pattern (or new API, but same pattern) which could possibly allow for more user API customisation.

Something like:

// returns null until the resource is loaded
const items = this.meta(MyResource).getOrRead();