Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Dojo ResourceProvider - Read Many API #5

Closed
wants to merge 35 commits into from

Conversation

agubler
Copy link
Member

@agubler agubler commented Feb 22, 2019

Initial resources abstraction to provide mechanism to inject a provider into an application and an API to fetch resources based on the configuration passed.

  • Scaffolds the resource package
  • Initial getOrRead API - this API either runs the specified function to fetch resources and subsequently returns cached resources
  • Pagination support with getOrRead
  • next and prev API to work with pagination
  • Restful configuration for fetching resources from a remote REST server
  • README documentation
  • Unit tests

Related to #2

.gitignore Outdated
@@ -1,2 +1,5 @@
node_modules
dist
resources.old
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove


// status(): string

// const a: ResourceState<any> = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping this for now as describes the desired data model for resources

}

if (currentStatus.status !== 'completed' || this._initial) {
const handle = this._store.onChange(this._store.path(pathPrefix), () => {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can probably only invalidate on changes to the data path as it's all this API is interested in

} = {
many: {
read: {
optimistic: true,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does optimistic make sense as a possible option on reading/fetching resources? Possibly not as we cannot optimistically update the store like we can for update/create/remove

@aciccarello
Copy link

Looks interesting @agubler! So is the provider the primary API? Are you able to get other items from the store from a resource provider? Most of the time our providers are combining several different things. A processor factory seems like a more reusable part of this from what I've gathered. Am I thinking about this correctly?

@matt-gadd
Copy link

matt-gadd commented Apr 12, 2019

@aciccarello Yeah the primary api is via the Provider. No you won't be able to access other parts from the Store as part of the Resources api (all Store related things are considered opaque in Resources, we are actually likely to factory our own internal Resource Store rather than using the users Store).

@matt-gadd
Copy link

matt-gadd commented Apr 12, 2019

when we eventually move this from a Provider to the new more generic meta api composing multiple resources will look like something like this:

render() {
  const todoResource = use(TodoResource);
  const someOtherResource = use(SomeOtherResource);
  const todos = todoResource.getOrRead();
  const [someOther] = someOtherResource.getOrRead();
  return todos.map(todo => (
    <div>
      <div>{someOther.yay}</div>
      <div>{todo.id}</div>
      <div>{todo.title}</div>
      <div>{todo.completed ? "completed" : "incomplete"}</div>
    </div>
  ));
};

@agubler
Copy link
Member Author

agubler commented May 29, 2019

closing as this was a POC that will be superseded

@agubler agubler closed this May 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants