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

Add initial implementation #3

Merged
merged 31 commits into from
Apr 25, 2016
Merged

Add initial implementation #3

merged 31 commits into from
Apr 25, 2016

Conversation

morrisallison
Copy link
Contributor

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

@morrisallison
Copy link
Contributor Author

One point of concern is when calling next(), prev(), first(), last(), or current() repeatedly without waiting for requests to finish. I was going to add a request queue, but I figured I grab some opinions first.

@@ -0,0 +1,33 @@
# Logs
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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?)

@LionOps
Copy link
Contributor

LionOps commented Mar 30, 2016

One point of concern is when calling next(), prev(), first(), last(), or current() repeatedly without waiting for requests to finish. I was going to add a request queue, but I figured I grab some opinions first.

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;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@beck
Copy link
Contributor

beck commented Apr 1, 2016

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)
Copy link
Contributor

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.

Copy link
Contributor Author

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

@snitch
Copy link

snitch commented Apr 21, 2016

✨ No lint errors found. ✨

@coveralls
Copy link

Coverage Status

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.
Copy link
Contributor

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 }
Copy link

Choose a reason for hiding this comment

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

Missing semicolon.

Copy link
Contributor

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.

@snitch
Copy link

snitch commented Apr 21, 2016

✨ No lint errors found. ✨

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 088ced4 on morris/initial into * on master*.

@LionOps
Copy link
Contributor

LionOps commented Apr 22, 2016

👍 (since @euwest is also reviewing, let's get a second thumbs! It's a huge PR.)

return null;
};

export const parseResponse = function(response) {
Copy link

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?

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 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.

@snitch
Copy link

snitch commented Apr 22, 2016

✨ No lint errors found. ✨

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 5b1b7f3 on morris/initial into * on master*.

const count = response.count;
const resultCount = response.results.length;

if (count > resultCount) {
Copy link

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?

Copy link
Contributor Author

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.

@euwest
Copy link

euwest commented Apr 25, 2016

For better or worse, the tests themselves are also included in the coverage results.

I'm guessing that's a side effect of having the tests mixed in with the implementation files.

@snitch
Copy link

snitch commented Apr 25, 2016

✨ No lint errors found. ✨

@morrisallison
Copy link
Contributor Author

I'm guessing that's a side effect of having the tests mixed in with the implementation files.

Yeah, I tried a bunch of different ways and just settled on that. I don't mind.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 670abb9 on morris/initial into * on master*.

@euwest
Copy link

euwest commented Apr 25, 2016

👍 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.

@morrisallison morrisallison merged commit ed093c2 into master Apr 25, 2016
@morrisallison morrisallison deleted the morris/initial branch April 25, 2016 20:35
@LionOps
Copy link
Contributor

LionOps commented Apr 25, 2016

Closes #1 and #2

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.

8 participants