-
Notifications
You must be signed in to change notification settings - Fork 130
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
Search for apps by title #762
Conversation
This comment has been minimized.
This comment has been minimized.
f4fad65
to
39fb85e
Compare
packages/app/src/cli/prompts/dev.ts
Outdated
const fetchInterval = setInterval(async () => { | ||
let input: string | undefined | ||
do { | ||
input = allInputs.pop() |
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.
Do we need to keep track of all inputs? I get that going back is going to be faster this way, but we're also going to hit the API many times, when most likely only the results returned by the last input will be used.
What if instead we performed a debounced search only when the user has stopped typing for like 500ms. This should cover the most common scenario and only perform one query.
I still like the idea of caching results so that if you search for something, add some characters and go back we don't fetch again, but I feel like doing extra queries just in case might be a bit wasteful here for the most common scenario.
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 like this idea, also avoids blocking for 1 second when the user is in the middle of typing. I'll think about how to implement efficiently.
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'd use the debounce function from lodash, since we already have it in the project
packages/app/src/cli/prompts/dev.ts
Outdated
* Otherwise, display the result of whatever intermediate step is | ||
* available, so the user at least sees something is happening. | ||
*/ | ||
return cachedFiltered[latestRequest] || cachedFiltered[input]! |
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 wonder wether this behavior might be a bit surprising if compared with typical web autocomplete. Could we instead display no results for ${input}
, or something similar?
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 don't fully understand this comment, and I would love some more context.
Which scenario is surprising to you? What would you expect instead?
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.
Sorry if I misunderstood the code but from what I can tell if I type hello
and there are no results for "hello", I would be a bit surprised to find results for hell
. What I would expect from the UI is to tell me that there are no results. But maybe showing something is better than nothing, even if it's not 100% relevant. Not sure.
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.
So, imagine that I type "hello" and we are loading results as we go.
If we just received results for hell
we would show them until the results from hello
return, and then even if the hello
results are empty, we'd replace the hell
results with a statement that no results were found.
So the pecking order is:
Results from the latest input, even if empty > The most recently returned results, if not empty > "Searching..."
This may matter much less anyway if we're using the debouncing strategy mentioned above.
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.
Got it, that makes sense 👍 And yes this will probably matter less if we go with a debouncing strategy.
39fb85e
to
684bd77
Compare
Previously, if the result wasn't part of the initial set of returned apps, it wasn't found. This fixes the bug.
We only need the API key since we'll follow up by fetching full app info anyway!
99c4d35
to
342542b
Compare
Coverage report
Show files with reduced coverage 🔻
Test suite run success863 tests passing in 435 suites. Report generated by 🧪jest coverage report action from 3e318d9 |
0b16e71
to
00b1a26
Compare
00b1a26
to
3e318d9
Compare
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.
LGTM 👍
Sorry coverage report, this kinda thing is just going to make you sad. 😢 |
WHY are these changes introduced?
Fixes #317
Currently Partners can't select an app that's too far down in their org's list of apps. They need to work around using the
--api-key
flag. This PR allows Partners to search by app title if their app count exceeds the number we fetch.Videobin
WHAT is this pull request doing?
I think this is best explained by seeing the code comments, which describe the algorithm at length.
TL;DR if they have >100 apps in the organization, typing to search triggers a call to the Partners API searching for the apps by title.
How to test your changes?
Acting as a 1P developer, connect to the Shopify partners organization and search for an app far down the list.
Measuring impact
How do we know this change was effective? Please choose one:
Checklist
dev
ordeploy
have been reflected in the internal flowchart.