-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add initial implementation #3
Conversation
One point of concern is when calling |
@@ -0,0 +1,33 @@ | |||
# Logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a point to this file? Snitch doesn't need it, and all of our other libs don't have one either. If Snitch did need it, it'd make sense, but I think it can go. If you do see a use case, share.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is the same as the gitignore, why not symlink it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad, I was using it for local changes not in this PR yet. It isn't needed (yet?)
How would the request queue work? I think that calling them repeatedly should return a promise for the next page. There is a risk that next is called more times than actual pages, but I think we can have documented behavior around that. Calling next() on a page that doesn't exist should resolve to the same error regardless if it's a known limit or not. Knowing the page count should merely prevent the request actually being made. |
|
||
|
||
const limit = 50; | ||
const style = Paginator.styles.limitOffset; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does the paginator need a configured "style"? Shouldn't the behavior be determined by given options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The style
option determines what queryParams
are sent to the request. Requests aren't supposed to interpret the query params, but only serialize them. This way the paginator is configured to match the request rather than the other way around.
I'm a little surprised a class is used instead of a more functional approach. Notice that there is a proposal for Async Iterator for which FB has already written a polyfill? Not saying this is the needed approach, but it would feel more contemporary. |
- Indicates which pagination style to use. | ||
- Currently supports: | ||
- [`PageNumberPagination`](http://www.django-rest-framework.org/api-guide/pagination/#pagenumberpagination) | ||
- [`LimitOffsetPagination`](http://www.django-rest-framework.org/api-guide/pagination/#limitoffsetpagination) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing our endpoints, do we support LimitOffsetPagination
anywhere? Supporting alternate pagination styles seems like a feature that could come after the initial release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's not needed now. However, when writing the paginator, I wanted to ensure it was flexible enough to adapt to the other styles. Taking it out now wouldn't change much of the code. I also saw this https://github.com/yola/production/issues/3061#issuecomment-193303279
✨ No lint errors found. ✨ |
Changes Unknown when pulling 9de4f7b on morris/initial into * on master*. |
This is a [getter][mdn-defineproperty] property. | ||
|
||
[mdn-defineproperty]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty | ||
This is a property is read-only. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grammarize
_rejectPage(page) { | ||
const message = `Invalid page "${page}".`; | ||
const error = new Error(message); | ||
error.response = { detail: message } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing semicolon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this also caused tests to break.
✨ No lint errors found. ✨ |
Changes Unknown when pulling 088ced4 on morris/initial into * on master*. |
👍 (since @euwest is also reviewing, let's get a second thumbs! It's a huge PR.) |
return null; | ||
}; | ||
|
||
export const parseResponse = function(response) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious why this is called parseResponse
when it seems to just be adding page count and limit attributes to the response?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I called it parse since it's only pulling out the properties of the response it cares about, and creating a new object.
However, I do see where you're coming from. The function is really only calculating the pageCount
. I'll refactor it to do only that.
✨ No lint errors found. ✨ |
Changes Unknown when pulling 5b1b7f3 on morris/initial into * on master*. |
const count = response.count; | ||
const resultCount = response.results.length; | ||
|
||
if (count > resultCount) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's a scenario where this is true, and why would that arise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When a query has multiple pages, that expression will always be true for the first page response.
The times when it's not true, is on the last page, or when there are no results.
I'm guessing that's a side effect of having the tests mixed in with the implementation files. |
✨ No lint errors found. ✨ |
Yeah, I tried a bunch of different ways and just settled on that. I don't mind. |
Changes Unknown when pulling 670abb9 on morris/initial into * on master*. |
👍 let's make a ticket for fleshing out the readme and API docs. as is, they aren't helpful if you don't know anything about the module. |
Parents: #1 #2
Additional properties and methods were added, but I only consider
clone()
to be supplementary. I'm working on writing integration tests for a tiny DRF service.🔔 ping @yola/frontend-engineering