-
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
Filter app results by title #4630
Conversation
We detected some changes at either packages/*/src or packages/cli-kit/assets/cli-ruby/** and there are no updates in the .changeset. |
Coverage report
Test suite run success1961 tests passing in 890 suites. Report generated by 🧪jest coverage report action from c55df5d |
CC @amcaplan Note that as part of https://github.com/Shopify/shopify/pull/539421, I introduced the connection API but I also preserved the old
This PR is probably broken if it's using
Or if you feel comfortable moving fast and breaking things, go ahead. I'm not opposed to that with good comms around it in our project channel. I just didn't want to take that on myself :) |
@amcaplan should we aim to get this shipped? |
378d9d0
to
33a3c20
Compare
We detected some changes at packages/*/src and there are no updates in the .changeset. |
33a3c20
to
4de2e9f
Compare
I think this is ready to go. Currently it points to |
pnpm-lock.yaml
Outdated
@@ -279,7 +279,7 @@ importers: | |||
version: link:../app | |||
'@shopify/cli-hydrogen': | |||
specifier: 9.0.2 | |||
version: 9.0.2(react-dom@18.2.0)(react@18.2.0) |
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 think this file should have changed?
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 honestly have no idea sometimes why these things change... maybe my local version of pnpm is slightly off? But I'm on 8.15.7 so 🤷♂️
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.
It seems like a rebase eliminated this change. Looks like this snuck in inside someone else's PR...
appModules { | ||
...ReleasedAppModule | ||
query listApps($query: String) { | ||
appsConnection(query: $query, first: 50) { |
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.
Check -- we're going from all (presumably -- ignore if not) to 50. How does that match up to partners? Do we have sane ordering for these (e.g. most recent first)?
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.
first
is required, so we need to pass some kind of value here.- 50 seems reasonable, I don't think we should have users scrolling manually beyond that.
- I thought I recalled Partners using 50 as the max, but I can't seem to find it at the moment... That said, client-side we limit it to 25 here. So it's the same order of magnitude. Maybe worth checking, but it's easily changed and not a reason to hold up the PR at the moment IMO.
- Order is the default dictated by the server, currently the most recently updated. It will match what they see in the dashboard; it feels like consistency is good.
}) | ||
} | ||
|
||
test('passes in a blank search if none is provided', async () => { |
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 is a case where a parameterised test would be best - https://vitest.dev/api/#test-each
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.
Oh, neat! I wasn't aware of how to do this.
} | ||
|
||
test('passes in a blank search if none is provided', async () => { | ||
await appSearchTest({query: undefined, queryVariable: ''}) |
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.
Given that the default behaviour is term = ''
can we get a test asserting that query stays empty in that case.
} | ||
const result = await appManagementRequestDoc(organizationId, query, await this.token(), variables) | ||
if (!result.appsConnection) { | ||
throw new AbortError('Server failed to retrieve apps') |
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 is a BugError
. Things are pretty broken if this happens
4de2e9f
to
08bd462
Compare
08bd462
to
c55df5d
Compare
WHY are these changes introduced?
Fixes https://github.com/Shopify/develop-app-inner-loop/issues/1861
Pairs with https://github.com/Shopify/shopify/pull/539421 to enable filtering by app title in the new API.
Note this should NOT be merged until that PR is merged.
WHAT is this pull request doing?
Updates the format of the request to work with the new paginated field, and passes in the search term as a query for app title.
Note that each token is considered an independent search term, so we're searching for an app title that includes all mentioned tokens.
How to test your changes?
filter-using-pagination-system
branch (update as of 2024-11-14: this works onmain
ordd
as well)USE_APP_MANAGEMENT_API=1 bin/spin pnpm shopify app config link --path /PATH/TO/YOUR/APP
Measuring impact
How do we know this change was effective? Please choose one:
Checklist