Add resultKey option to handle common pagination responses #10
Conversation
|
@mirkokiefer This means you are paginating all your responses right? |
|
No, it still works for responses that don't have the responseKey. |
|
@mirkokiefer Well unless you somehow return a response with that key in it? |
|
That's true - but not sure how this could be avoided. We would need some kind of per-route config option. |
| it('Uses the result key', (done) => { | ||
|
|
||
| const result = { | ||
| items: [{ |
There was a problem hiding this comment.
Can you add a page: 1 property in the result so it mimics the use case as close as possible?
| @@ -48,3 +48,30 @@ Or do `GET /users.csv`. | |||
| The header approach is prefered. | |||
|
|
|||
| Currently the `content-disposition` header is set to `attachment;` by default since this plugin is intended for exporting purposes, if this hinders you just let us know. | |||
|
|
|||
| To handle typical pagination responses like | |||
There was a problem hiding this comment.
I might be worth noting that this will apply to all routes/export cases.
Also we might want to add a section to explain all options but that is not for the scope of this PR :P
| @@ -466,4 +466,78 @@ describe('Hapi csv', () => { | |||
| }); | |||
| }); | |||
| }); | |||
|
|
|||
| describe('Result key (e.g. for pagination)', () => { | |||
There was a problem hiding this comment.
I would like to also see a test case with the resultKey option where the result does not have the key, just for good measure.
|
@mirkokiefer yeah that would get difficult unless we add some option you can set per route but if this solves your use case it's fine and if needed we can refine it later on |
|
Added the additional test. |
|
@kdeclerck up to you to merge, LGTM |
|
🎉 I will release a new version soon, I plan to also update the Joi version. |
|
@mirkokiefer I released version 2.5.0, thanks for the PR! |
No description provided.