-
Notifications
You must be signed in to change notification settings - Fork 22
Search filters for job list #344
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
Conversation
Another aspect to highlight about this search input: it attempts to behave as a single input in most ways, such as being able to use left/right arrows to continuously move the cursor between filters. Ideally it should be easy to use only the keyboard or to avoid needing to switch between input modes repeatedly. |
brandur
left a comment
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.
Cool, thanks for taking a look.
Issue #347 details how #344 broke some key parts of the frontend due to missing fields in the job list payloads (errors, logs, and metadata were removed from the job payload for the list API). The root issue is that the TypeScript types were not adjusted to reflect the new split Job type, so several parts of the code made reference to things they could no longer access (and didn't actually need anyway). In particular this was true for deserializing job payloads where the same logic was applied to all job responses. To fix this, update the types to have a separate `JobMinimal` and `Job` type just as the API backend does. Update all code that uses them to ensure the correct one is utilized. It's only list view stuff that needs `JobMinimal` for now. Fixes #347.
Issue #347 details how #344 broke some key parts of the frontend due to missing fields in the job list payloads (errors, logs, and metadata were removed from the job payload for the list API). The root issue is that the TypeScript types were not adjusted to reflect the new split Job type, so several parts of the code made reference to things they could no longer access (and didn't actually need anyway). In particular this was true for deserializing job payloads where the same logic was applied to all job responses. To fix this, update the types to have a separate `JobMinimal` and `Job` type just as the API backend does. Update all code that uses them to ensure the correct one is utilized. It's only list view stuff that needs `JobMinimal` for now. Fixes #347.
Issue #347 details how #344 broke some key parts of the frontend due to missing fields in the job list payloads (errors, logs, and metadata were removed from the job payload for the list API). The root issue is that the TypeScript types were not adjusted to reflect the new split Job type, so several parts of the code made reference to things they could no longer access (and didn't actually need anyway). In particular this was true for deserializing job payloads where the same logic was applied to all job responses. To fix this, update the types to have a separate `JobMinimal` and `Job` type just as the API backend does. Update all code that uses them to ensure the correct one is utilized. It's only list view stuff that needs `JobMinimal` for now. Fixes #347.



This adds complex faceted search filters to the job list UI to filter by kind, ID, priority, or queue. The UI supports essentially all keyboard and mouse/touch input, including navigation between filter items.
Not every combination of search here will be efficient at the database level, but this isn't a typical runtime query—it's a debugging tool for operators. Some risk here should be acceptable, and can be mitigated by setting appropriate query timeouts on the pool given to the UI's River client.
autocomplete.mp4
Fixes #242.