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

Allow to resolve buttons on QuickPickItems lazy #131401

Closed
dbaeumer opened this issue Aug 23, 2021 · 5 comments
Closed

Allow to resolve buttons on QuickPickItems lazy #131401

dbaeumer opened this issue Aug 23, 2021 · 5 comments
Assignees
Labels
quick-pick Quick-pick widget issues under-discussion Issue is under discussion for relevance, priority, approach

Comments

@dbaeumer
Copy link
Member

I need to resolve the buttons for QuickPickItems lazily (e.g. I need to make service requests). Currently I need to set the items on the quick pick which can lead to strange behavior if the user types, moves the mouse or otherwise interacts with the quick pick.

Would it be possible to support a style where setting the buttons property updates the item in the UI?

@TylerLeonhardt
Copy link
Member

TylerLeonhardt commented Aug 23, 2021

This is interesting and not currently supported even in Core atm. I wonder though if this issue would be almost fixed with addressing this:
#109969

The fix for that being that if the same ids are present when you set .items then the cursorTop won't change (but the UI will still update if a button was added or changed).

(of course the concept of ids would need to be exposed to extensions)

@TylerLeonhardt TylerLeonhardt added under-discussion Issue is under discussion for relevance, priority, approach quick-pick Quick-pick widget issues labels Aug 23, 2021
@dbaeumer
Copy link
Member Author

That would definitely help. Do you know why we decided that QuickPickItems are not live at least in the case where I create a quick pick list using the API?

@TylerLeonhardt
Copy link
Member

It's a good question. Historically it seemed like we didn't want to complicate the API too much:

The assumption so far was that items would not change and that we need to read their properties only once when they are set on the picker object. That has kept the API simple. The scrollTop and splice() (replace the changed items) suggestions are preserving this assumption.

If we wanted to support mutable items, we would need an extension-supplied event. That would in my view mix two distinct approaches in the same API.

from @chrmarti in #109969

It would get a bit complicated because the user is responsible for creating the QP items...

for most cases, simply preserving the cursor top when the QP items have the same ids and order is enough of a fix and the user just needs to add an id

(this again is theoretical since today there's no concept of an id in the extension QP items)

@TylerLeonhardt
Copy link
Member

I just added the proposed API for a property that you can set that will allow you to control when the scroll position should be kept. That's being tracked here:
#132068

It's not quite as elegant as enabling "live objects" in the quick pick but it should be enough to fix your issue without having to break the previous assumption that the items were static.

@TylerLeonhardt
Copy link
Member

Closing this to use that ^

@github-actions github-actions bot locked and limited conversation to collaborators Nov 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
quick-pick Quick-pick widget issues under-discussion Issue is under discussion for relevance, priority, approach
Projects
None yet
Development

No branches or pull requests

2 participants