Add sort dropdown to packages pane#13060
Conversation
|
E2E Tests 🚀 |
|
@bricestacey This looks good for MVP Non blocking comments
|
| const sortActions = (): IAction[] => { | ||
| return [ | ||
| { | ||
| id: 'sortNameAsc', |
There was a problem hiding this comment.
Perhaps positronPackages.sortNameAsc.
There was a problem hiding this comment.
I believe these require an id for the sake of conforming to the IAction interface, which we reuse for the Positron action bars. Otherwise, we will never reference these action and they're never registered in anything where an id matters.
It could be a random UUID, correct? If so, if anything I would replace it with generateUuid() to remove the ambiguity of the ability for reuse or their stable nature, but I think it's fine as-is to use a unique string.
Do you have an opinion?
If I am correct, I think we probably shouldn't require the PositronActionBar to conform strictly to the IAction. Instead, we should use Pick<IAction, 'foo', 'bar'> & { id?: string } to make the id optional... and randomly generate it when not provided if we even need it.
A parallel path might be to define IActions independent of the implementation and pull them in from an export versus inline. Then, id perhaps would be meaningful.
| run: () => setSortOrder(PackagesSortOrder.NameAsc) | ||
| }, | ||
| { | ||
| id: 'sortNameDesc', |
There was a problem hiding this comment.
Perhaps positronPackages.sortNameDesc.
Resolve merge conflicts in listPackages.tsx: - Incorporate new ActionBarFilter props (showClearAlways, clearButtonIcon, size) - Add handleFilterTextChanged to clear selection on filter change - Add empty state message when no packages match filter - Keep sort dropdown and action bar structure
We'll be adding more, but this the absolute minimal MVP to get the feature going. Once we have started to sync metadata from a 3rd party API (e.g. #12928), we can layer in additional sorts.
Maybe I should match the data explorer and make a note to review.
Agreed, I think the Extensions sidebar is a good example to imitate. This current implementation that has the sort (and in #13112 it also includes the category filter) on a separate row with no other controls to justify the additional actionbar seems superfluous. |
This was intentional because "Name (A-Z)" seems excessive. The label "Name" is sorted alphabetically and alphabetically sorted lists are naturally sorted A-Z so "Name" is sufficient. |
Replace the separate sort action bar with a filter icon button inside ActionBarFilter, which opens a context menu with a "Sort" submenu. The clear button now also resets the sort to the default (Name A-Z), matching the user expectation that "clear all" resets every filter. See #12924
Make the filter input the single source of truth for sort state. The input is parsed into free-text and an `@sort:<value>` token; selecting a sort option from the filter menu rewrites the input via the ActionBarFilter handle, which flows back through the normal input path. Parser leaves unknown `@...` tokens in place so future tokens (e.g. `@outdated`) display harmlessly until they're recognized. Drop the now-unused onClearButtonPressed hook — clearing the input resets sort through the same derivation. See #12924
Move parseQuery / applySortToQuery out of listPackages.tsx into a sibling packagesQuery.ts module so the grammar can be tested without pulling in React. Add unit tests covering sort tokens, case-insensitivity, multiple tokens, whitespace normalization, unknown-token pass-through, and a round-trip from applySortToQuery into parseQuery. See #12924
Previously parseQuery only consumed recognized @sort:<known-value> tokens; anything else (including @sort:bogus, @outdated, @author:hadley) fell through into free-text filtering, which matches no package names and leaves the user with an empty list until they hand-edit the token back out. Consume every @key[:value] shape the regex matches, even when the key or value is unrecognized. This future-proofs tokens like @outdated that are planned but not yet wired up, and keeps unknown input from silently poisoning the free-text filter. See #12924
Hoist the filter input text (the single source of truth for both free-text filter and sort) out of ListPackages' local React state and onto the instance, so switching panes, tabs, or runtime sessions no longer resets the user's filter and sort choice. On active-instance change the stored query is pushed into the filter input and debounced state synchronously so filtering doesn't flash stale results for 300ms after the switch. See #12924
This reverts commit f84375a.
There was a problem hiding this comment.
Sorry if I'm beating a dead horse, but generally, a drop down menu should display the selected value consistently:
Another issue I see is that if I click on an entry and start pressing up arrow and down arrow, the entry that is selected does not change and the entire list scrolls by some seemingly unrelated amount of pixels:
Screen.Recording.2026-04-22.at.3.50.37.PM.mov
Also, if I click twice on an entry, it gets a colored background, but pressing up arrow and down arrow doesn't do anything in this state:
Screen.Recording.2026-04-22.at.3.53.44.PM.mov
Perhaps these things are out of scope for this PR at this time. I'm mentioning them because Variables, also based on react-window, handles some of this (imperfectly) in keyDownHandler in src/vs/workbench/contrib/positronVariables/browser/components/variablesInstance.tsx.
|
I think you need to pull the latest @softwarenerd |









See #12924
Add an action bar with a sort action item that allows sorting packages by name and name (a-z). The selected sort order is shown in the label.
As a PositronDynamicActiomBar, we also include an overflow menu item the has the same options under a "Sort" submenu.
Demo:



Overflow behavior, note that sort is a submenu now:

Future work:
@sort:installsRelease Notes
New Features
Bug Fixes
QA Notes
@:packages-pane