Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
702e058 to
055a218
Compare
055a218 to
aeda0ef
Compare
9a6b47d to
e7aedeb
Compare
185fc8e to
d548dd0
Compare
e7aedeb to
be6fe2f
Compare
d548dd0 to
57641b0
Compare
be6fe2f to
3c9b2c8
Compare
57641b0 to
60e5301
Compare
a4e2ef4 to
e9ccb7d
Compare
3c9b2c8 to
a558f5b
Compare
f74981d to
fbe5916
Compare
713cdad to
7e04972
Compare
fbe5916 to
40b0fda
Compare
| if (filters.pipeline_name) count++; | ||
| if (filters.annotations && filters.annotations.length > 0) { | ||
| count += filters.annotations.length; | ||
| } |
There was a problem hiding this comment.
Hmm, it's interesting that we have dedicated business logic for determining the active filters count. As opposed to just checking the length of active filters; Assuming there is a source of active filters or active filters actually mean something beyond just a count.
The reason I mention this is because with this business logic not just being a simple length check from a better source of truth, I could see this function diverging in the future and becoming inaccurate.
There was a problem hiding this comment.
I agree this was a maintenance hazard. I refactored countActiveFilters to derive from serializeFiltersToUrl as the source of truth for which filters are active, rather than manually enumerating each field. Now new scalar filter fields are automatically counted via a generic Object.keys loop, and only the fields that need special counting logic (date range grouped as one, annotations counted individually) are explicitly special-cased. This way the function stays accurate as the PipelineRunFilters type grows.
22e0cd0 to
e2dc28d
Compare
4df5ece to
baaaa48
Compare
8ecc3fd to
757b00a
Compare
5ec1579 to
0c832cc
Compare
757b00a to
376ee50
Compare
0c832cc to
13eccc4
Compare
| const handleKeyDown = (e: KeyboardEvent<HTMLInputElement>) => { | ||
| if (e.key === "Enter" && keyInput.trim()) { | ||
| e.preventDefault(); | ||
| handleAdd(); | ||
| } | ||
| if (e.key === "Escape") { | ||
| setIsExpanded(false); | ||
| setKeyInput(""); | ||
| setValueInput(""); | ||
| } | ||
| }; |
There was a problem hiding this comment.
I'm surprised these shortcuts are not already handle by our Input component?
There was a problem hiding this comment.
Our Input is a thin styling wrapper around <input> — it doesn't handle any keyboard shortcuts. These are also app-specific behaviours (Enter = submit filter, Escape = collapse and reset), so they wouldn't really belong in a generic input primitive.
There was a problem hiding this comment.
Hmm. Maybe we should consider if there's value adding onEscape and onEnter props to our input component and providing some base level of support. (separate to this PR)
src/components/shared/AnnotationFilterInput/AnnotationFilterInput.tsx
Outdated
Show resolved
Hide resolved
376ee50 to
dd5fc17
Compare
13eccc4 to
e072f6e
Compare
e072f6e to
5c53819
Compare
There was a problem hiding this comment.
This seems fine but it's hard to evaluate given the full E2E feature isn't implemented. e.g. I have no idea what the EditableAnnotationBadge looks or functions like because the app crashes (by design?) when I try to add a filter
Even though this is just a UI preview it should still function without crashing. Is it possible to just mock the flow instead of actually waiting and expecting anything from the backend? e.g. just store the k:v annotation pairs in an array and render them
5c53819 to
0be99fb
Compare
dd5fc17 to
00e3822
Compare
0be99fb to
00dbf7b
Compare



Resolves: https://github.com/Shopify/oasis-frontend/issues/458
Description
Adds an annotation filter input component for filtering pipeline runs by key-value annotation pairs.
Note: This is a UI-only preview. The filters update the URL but are not properly connected to the API, causing a broken search state. This is resolved in a later PR in the stack.
Type of Change
Changes
AnnotationFilterInputcomponent with:PipelineRunFiltersBarChecklist
Test Instructions