App Bridge - ResourcePicker - InitialQuery not hidden on subsequent requests

[DiscountNinja]

When using the ResourcePicker component from AppBridge the initial query is hidden when a resource picker is displayed the first time. This is the expected results.

On subsequent open actions however, the initial query is visible. This seems incorrect.

The behavior on subsequent open actions is not a desirable outcome for two reasons: 

- the outcome is not consistent when comparing first and subsequent opens

- the initial query should not be visible on subsequent opens. It should be hidden to avoid that users can override the filter

How can we avoid this behavior and ensure the initial query is always hidden?

Here's an (incomplete) code snippet that shows how we create a picker in plain Javascript:

... create app and create variable ResourcePicker

let picker = ResourcePicker.create(app, {
                    resourceType: ResourcePicker.ResourceType.Collection,
                    options: {
                        initialQuery: '... query ...',
                        selectMultiple: true,
                        showHidden: false
                    }
                });

picker.subscribe(ResourcePicker.Action.SELECT, function (selection) { ... });
picker.dispatch(ResourcePicker.Action.OPEN);

[iain-campbell]

Hi Bart,

Thanks the thorough bug report! I’ve reproduced the bug and opened an issue. I’ll post updates here.

Iain

[Kris_Doyle]

Hey @iain-campbell ,

Since my release this past weekend, the App Bridge v1.9.0 picker is now in production and I'm getting complaints about this:

Do you have any updates on this particular issue? Just not sure what to tell my users 🙂

It's causing a lot of confusion since deleting the text changes the context.

Thanks!

Kris

[DiscountNinja]

Hi Ian,

It's been six weeks.

What's the ETA on this?

Regards,

Bart

[iain-campbell]

Hi Bart, Kris,

I’ve done some research and it looks like your desired behaviour—setting a non-user-editable query filter—is actually an unintended side effect. Technically, the bug here is that initialQuery is hidden.

However, we would like to support your use case. To help inform our design of this feature: is it more important to you that the user can’t see the filter, or that the user can’t edit the filter?

[DiscountNinja]

Thanks for your reply Ian.

Here's my feedback:

If I have to chose the most important for me is that the user cannot edit the filter.

This will ensure that the lookup provides the intended filter only.

Preferably they should also not see the filter since it is of a technical nature and has little added value to those who are not familiar with the query language and Shopify's entity model.

And ideally both the option to see and edit should be configurable.

[Kris_Doyle]

Hi Iain,

I would echo Bart's comments completely. It's odd that it would work the way it does now, since everyone that's seen it (including customers and Shopify staff) have all assumed it was a bug 🙂

In any case, I think Bart nailed it. I also agree that if it were configurable (i.e. initialQuery, initialQueryEditable, initialQueryVisible) it would allow the developer to tailor the behaviour. I see what Shopify was trying to do by offering the initialQuery param, since there could be benefits to making this visible initially, but as Bart said, the way it is at the moment isn't adding value and is confusing. It's been reported by two of my users so far.

The other thing I'll mention is that I have two users that are regularly getting the following Server Error message (reported by uk-wantapothecary):

I believe the apps team is already aware of it, but it's happening pretty consistently, especially today for the client I mentioned. It can be hard to reproduce as there are no clean repro steps.

Bart, have you ever seen that? Or any of your users?

Thanks very much Iain!

Kris

[iain-campbell]

Thanks for the feedback! So both of you would prefer to have full control over the initial query: whether it exists, whether it's editable, and whether it's viewable. I’ll take this to our design team.

We’ve been in contact with support regarding that 'Server error' message. They are investigating. I agree that the error looks scary, but it’s likely just be a query timeout. Annoying, for sure, but not an indication of data corruption or anything like that.

[Kris_Doyle]

Thanks Iain,

Yes, I would agree with that statement but I would add that I personally thought that, that would be the default behaviour. I think the params would make it more flexible for others developers though. Myself, I would be fine if it was not editable and not visible since that’s what I expected originally. IMHO of course 🙂

Thinking about it now, I’m struggling to find a use case where the current initialQuery behaviour would be used.

Anyways, about the 500 error, I suspect that’s probably the same error I’m seeing quite a bit in my logs for other regular GraphQL calls for the collections/products endpoint. 50+ day during the week typically during higher traffic periods. Any chance it’s related to the release of the bulk API addition?

My users are getting pretty frustrated about it unfortunately 😞

Thanks!
Kris

[iain-campbell]

Anyways, about the 500 error, I suspect that’s probably the same error I’m seeing quite a bit in my logs for other regular GraphQL calls for the collections/products endpoint. 50+ day during the week typically during higher traffic periods. Any chance it’s related to the release of the bulk API addition?

Have you shared your logs with the support team?

[Kris_Doyle]

Hi @iain-campbell ,

Yes, I had sent a list of request IDs to Ignacio when I first started having the issue. I probably have several 100 of these now.

It's odd, I never had these issues with the REST API. I'm using cursors with a request size of 50.

[DiscountNinja]

Hi @iain-campbell,

It's been 3 months now since this problem was identified.

Do you have a status update on this?

Regards,

Bart

[DiscountNinja]

Hi @iain-campbell,

Has this issue been addressed?

We really need the ResourcePicker to work correctly.

Our only workaround was to use our own resource picker. We built one a while ago, but the backward-incompatible changes made in the Product and Collection REST APIs (2019-07) are breaking this workaround. That is because the Product and Collection APIs no longer support searching for a partial match of the product title or collection title (https://shopify.dev/concepts/about-apis/versioning/release-notes/2019-07).

That means, as of July (initially April) 2020 there is no fully functional, supported way to allow users to pick products/collections/variants in our apps.

Can we please get an update? It's been 6 months since we reported this.

Regards,

Bart

[Ankita_patel]

how can I hide initQuery from ResoucePicker?

[DiscountNinja]

I have opened a GitHub feature request here https://github.com/Shopify/polaris-react/issues/2909

Please visit it and give it a thumbs up to upvote this request.

[den232]

I would like to echo the request for (initialQueryEditable, initialQueryVisible) options.   I'm looking to limit selection choices to one product type, but NOT have the techy initial selection text visible.  Is there any approved way to do this?