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

Add REST store support #48

Closed
wants to merge 1 commit into from
Closed

Add REST store support #48

wants to merge 1 commit into from

Conversation

lzhoucs
Copy link
Contributor

@lzhoucs lzhoucs commented Nov 15, 2016

Type: feature

Description:
Add a REST based storage that interacts with a target REST endpoint remotely. Refactored createInMemoryStorage

Related Issue: #47 , #4

Please review this checklist before submitting your PR:

  • There is a related issue
  • All contributors have signed a CLA
  • All code matches the style guide
  • The code passes the CI tests
  • Unit or Functional tests are included in the PR
  • The PR increases or maintains the overall unit test coverage percentage
  • The code is ready to be merged

@lzhoucs lzhoucs changed the title Rest storage Add REST store support Nov 15, 2016
@lzhoucs
Copy link
Contributor Author

lzhoucs commented Nov 15, 2016

All tests passed. The build is hanging on "Created session iphone 9.3 on any platform". It doesn't seem to be caused by my changes.

});
}
},
const createInMemoryStorage: InMemoryStorageFactory = createBaseStorage.mixin(compose({
Copy link
Contributor

Choose a reason for hiding this comment

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

If we're using mixin(), is there a reason we're also using compose(), or could we just pass a mixin descriptor? e.g.

{
  mixin: {
    createId(...)
    ...
  },
  initialize(instance, options) {
  }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah. That's a good idea and I tried it. But it doesn't seem to work. You can find the change in this branch

Copy link
Member

Choose a reason for hiding this comment

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

Does seem like a strange usage, should work with the format bradley used above

Copy link
Contributor

Choose a reason for hiding this comment

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

This is now using a mixin descriptor argument instead of a factory.

uri += '/' + ids[0];
}
else {
uri += '?' + state.idSerializer(ids);
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably check if state.idSerializer exists and default to making individual get requests here if it doesn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. This makes sense to me. I will make the change here(get) as well as in delete

uri += '/' + ids[0];
}

return <Promise<any>> request(uri, {
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably check if state.requestSerializer exists and default to making individual put requests here if it doesn't.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This one is tricky. requestSerializer is used as the object => string serializer regardless of the type of the request. So it can't be used as an indicator of opt in custom request. I can probably add another option just for put custom request scenario, unless you have other ideas.

}
}, <T, O>(instance: Storage<T, O>, {target,
createIdTarget,
idSerializer = defaultIdSerializer,
Copy link
Contributor

Choose a reason for hiding this comment

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

The serializers used for multiple puts and multiple gets probably shouldn't be defaulted. If they are supporting non standard ways of doing things as a convenience we will probably want to make that an opt in behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree. I am making changes for this. For get and delete, I will repurpose idSerializer as the indicator, and for put, I will add another option, since requestSerializer is being used in multiple scenarios.

@dylans dylans added this to the 2016.11 milestone Nov 16, 2016
@lzhoucs
Copy link
Contributor Author

lzhoucs commented Nov 17, 2016

I made the discussed changes. Will do a rebase once other PRs are landed.

return itemArray.map(state.idFunction);
}
else {
return itemArray.map(function(item) {
Copy link
Member

Choose a reason for hiding this comment

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

return itemArray.map((item) => item.id);

const state = instanceStateMap.get(this);
const itemArray = Array.isArray(items) ? <IdObject []> items : [ <IdObject> items ];
if (state.idProperty) {
return itemArray.map((item) => {
Copy link
Member

Choose a reason for hiding this comment

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

return itemArray.map((item) => item[ state.idProperty ]);

headers: {
'Accept': state.contentType
}
}).then(function(response) {
Copy link
Member

Choose a reason for hiding this comment

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

utilise the arrow functions:
.then((response) => state.responseDeserializer(response.data.toString()));

},

'GET': {
'ids can\'t be empty'() {
Copy link
Member

Choose a reason for hiding this comment

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

Can you be a bit more descriptive with your names please. ie.
Should throw error when get called without ids

});
}
},
const createInMemoryStorage: InMemoryStorageFactory = createBaseStorage.mixin(compose({
Copy link
Member

Choose a reason for hiding this comment

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

Does seem like a strange usage, should work with the format bradley used above

@tomdye
Copy link
Member

tomdye commented Nov 22, 2016

Have only done a brief review.
Also why the usage of String(thing) all over the place over thing.toString()?

@lzhoucs
Copy link
Contributor Author

lzhoucs commented Nov 24, 2016

Thanks @tomdye for the review. I addressed the feedback.

Regarding the String over toString(), ideally none of them should be used since response.data is already a string. However there were some typing issues, so I used the String wrapper to get around the issue in 3 places. Anyway my latest commit have addressed them.

@tomdye
Copy link
Member

tomdye commented Nov 24, 2016

@lzhoucs I would imagine the typings issues you described are just that, and should be fixed via the typings? I'm probably wrong though. As a general rule we should avoid using any as much as possible.

@lzhoucs
Copy link
Contributor Author

lzhoucs commented Nov 24, 2016

You're right @tomdye. And I wouldn't be surprised if typing issues were fixed by typing changes. As you can see from my change, I added generic typing <string> when calling request.get so response.data will be string as expected, as such there's no need to do any type of conversion as I did with String() wrapper.

As for any, I did try not to use it as much as possible. If there's any place you think I can replace any with a concrete type, please let me know and I am happy to make the change.

@dylans dylans modified the milestones: 2016.11, 2016.12 Dec 5, 2016
@codecov-io
Copy link

codecov-io commented Dec 9, 2016

Codecov Report

Merging #48 into master will decrease coverage by 1.13%.
The diff coverage is 93.53%.

@@            Coverage Diff             @@
##           master      #48      +/-   ##
==========================================
- Coverage     100%   98.86%   -1.14%     
==========================================
  Files          16       18       +2     
  Lines        1166     1322     +156     
  Branches      204      241      +37     
==========================================
+ Hits         1166     1307     +141     
- Misses          0       10      +10     
- Partials        0        5       +5
Impacted Files Coverage Δ
src/store/createQueryTransformResult.ts 100% <ø> (ø) ⬆️
src/query/createFilter.ts 100% <ø> (ø) ⬆️
src/patch/createPatch.ts 100% <ø> (ø) ⬆️
src/storage/createInMemoryStorage.ts 100% <100%> (ø) ⬆️
src/store/createStore.ts 100% <100%> (ø) ⬆️
src/storage/createBaseStorage.ts 100% <100%> (ø)
src/storage/createRestStorage.ts 90.13% <90.13%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 900986c...31cb84c. Read the comment docs.

@maier49 maier49 mentioned this pull request Dec 14, 2016
7 tasks
@dylans dylans modified the milestones: 2017.01, 2016.12 Dec 20, 2016
@dylans dylans modified the milestones: 2017.01, 2017.02 Jan 31, 2017
@dylans
Copy link
Member

dylans commented Feb 1, 2017

This one was ready to land, but we're waiting for dojo/core#261 to land and then we'll refactor this on top of that.

Copy link
Member

@dylans dylans left a comment

Choose a reason for hiding this comment

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

This will likely need some refactoring when dojo/core#261 lands.

@dylans dylans modified the milestones: 2017.03, 2017.02 Feb 28, 2017
@dylans dylans added this to the 2017.04 milestone Mar 29, 2017
@dylans dylans removed this from the 2017.03 milestone Mar 29, 2017
@maier49
Copy link
Contributor

maier49 commented Apr 7, 2017

Closing in favor of #124 which has been rebased against the latest from master and works with the updated request API from dojo/core

@maier49 maier49 closed this Apr 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants