Skip to content

Add Code Search #120

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

Merged
merged 19 commits into from
Jan 10, 2019
Merged

Add Code Search #120

merged 19 commits into from
Jan 10, 2019

Conversation

robbecker-wf
Copy link
Contributor

@robbecker-wf robbecker-wf commented Nov 6, 2018

Overview

This adds support for code search to finish the code search part of #92
https://developer.github.com/v3/search/#search-code

Testing

  • pub run build_runner serve example
  • http://localhost:8080/search.html
  • Test out different combinations of searches

@Pacane
Copy link
Contributor

Pacane commented Jan 6, 2019

Is this ready to merge?

@robbecker-wf
Copy link
Contributor Author

Not yet, I'd like to make a code search example and verify everything works as expected.

@robbecker-wf
Copy link
Contributor Author

@Pacane @georgelesica-wf Ready for review and testing

@robbecker-wf
Copy link
Contributor Author

don't merge yet .. reworking catching rate limit errors

<p>
Github Token: <input type="text" id="token" size="50">
<button id=removeTokenBtn>Clear Github Token</button>
</p>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Switched to localStorage to preserve your token longer and provide a clear button to remove it.

@robbecker-wf
Copy link
Contributor Author

Ok, cleaned up and now using json_serializable. I tested rate limiting and searching with all the options. Ready for review again.

// into the first CodeSearchResults and complete with the combined results
if (results.length > 1) {
for (int i = 1; i < results.length; i++) {
results[0].items.addAll(results[i].items);
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't know much about the context, but this doesn't look right..?
You have a list of CodeSearchResults and you always add them to the same index. Does that mean we could return a single CodeSearchResult?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's right. The code search results can be multiple pages of responses, so up on L123 each CodeSearchResults is added to a list. Then once all the page responses are done and added to the list, in this onDone handler it takes all of the items from each CodeSearchResults "page" and appends them onto the first one. Then we complete the future on L132 with just the first CodeSearchResult in the list. That's the one that has the complete list of items returned from all pages.
Maybe all this would make a good code comment? ^

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, you know what .. your question made me think more about this. Having it iterate and accumulate the responses internally means it will eagerly fetch all the pages. To be more consistent with other parts of the API, I think the code search should return Stream<CodeSearchResults> instead and leave it up to the consumer to pull as many responses from the stream as they want.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's what I was thinking about. I was gonna write an example of how I'd see this done, but yeah.

@robbecker-wf
Copy link
Contributor Author

@Pacane Another consideration is the default number of pages (2) and results per page (30) mean that, by default, you will only get 60 results even if there are more matches.

I'm not happy with the API at this point. Ideally, I'd like to not have to specify the number of pages up front and be limited in the results. I'd prefer to get back a controlling "search" object that you can simply ask for more results if you want them and cancel and bail if you don't .. but not have to start over with a whole new search.

@robbecker-wf
Copy link
Contributor Author

@Pacane @georgelesica-wf I'm ok with this API. How do you feel about it?

Copy link
Contributor

@Pacane Pacane left a comment

Choose a reason for hiding this comment

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

That looks much better! Great job

@Pacane
Copy link
Contributor

Pacane commented Jan 9, 2019

Can this be merged or do you still have stuff to do on this PR?

@kevmoo
Copy link
Collaborator

kevmoo commented Jan 9, 2019

We should squash-merge this so the history stays pretty 😄

@kevmoo
Copy link
Collaborator

kevmoo commented Jan 9, 2019

@robbecker-wf – would you rebase and clean up this PR? you mixed some tweaks to the HTML example w/ the cod search changes

@kevmoo
Copy link
Collaborator

kevmoo commented Jan 9, 2019

@robbecker-wf – you'll have to rebase anyway, since I pulled in pkg:meta, too 😄

@robbecker-wf
Copy link
Contributor Author

Sure, I'll pull out the example changes to a new PR and squish things.

# Conflicts:
#	lib/src/common.dart
#	lib/src/common.g.dart
#	pubspec.yaml
- add changelog entry
- remove example updates
- un required pages and perPage
Don't do shenanigans with another stream controller, just map the stream from the pagination helper
This helps to limit network requests until consumers pull values
update the search example to use "await for"
Copy link
Collaborator

@kevmoo kevmoo left a comment

Choose a reason for hiding this comment

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

Update version?

@@ -9,6 +9,10 @@
- Made associated classes `ContributorStatistics` and
`ContributorWeekStatistics` immutable. Since these classes are only meant as
return values, we're not treating this as a breaking change.
- Added `Stream<CodeSearchResults> github.search.code(...)` search API
Copy link
Collaborator

Choose a reason for hiding this comment

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

Since there are new changes, this should be 4.1, right?

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, I suppose it should be 4.1. I'll bump the version in this PR.
Whoever merges are you ok using the github squash or rebase and merge functionality or would you rather I squash and forcepush?
image

@kevmoo
Copy link
Collaborator

kevmoo commented Jan 10, 2019 via email

@@ -1,5 +1,5 @@
name: github
version: 4.0.2-dev
version: 4.1.0
Copy link
Collaborator

Choose a reason for hiding this comment

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

...and in the changelog!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

🤦‍♂️

@kevmoo
Copy link
Collaborator

kevmoo commented Jan 10, 2019

rock!

@Pacane
Copy link
Contributor

Pacane commented Jan 10, 2019

Thank you!

@Pacane Pacane merged commit 32cc4f0 into master Jan 10, 2019
@robbecker-wf robbecker-wf deleted the code_search branch January 10, 2019 14:27
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.

6 participants
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy