-
-
Notifications
You must be signed in to change notification settings - Fork 361
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
Add type based filtering, improve filtering UX #1341
Conversation
… cells to a higher layer. Improve typing.
…rganize record action components
Codecov Report
@@ Coverage Diff @@
## master #1341 +/- ##
=======================================
Coverage 93.71% 93.71%
=======================================
Files 114 114
Lines 4439 4439
=======================================
Hits 4160 4160
Misses 279 279
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
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.
This is awesome! The UX improvements are great, and it's really exciting to see type-specific options for the filter entries.
I'm merging, but I've also noted some lower-priority code questions and feedback that we can address later.
|
||
export class Filtering { | ||
readonly combination: FilterCombination; | ||
combination: FilterCombination; |
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.
I notice you've removed readonly
in a number of places. Why? It's not a big deal -- I'm just curious. My intent when building these low-level data structures was to make them immutable. I'm aware that TypeScript's readonly
marker isn't perfect, but I like how it communicates intent (and goes some of the way towards insuring immutability).
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.
Ahh. I forgot to revert this. At one point I was trying to make the entire Filter component reactive towards meta.filtering
when the Dropdown is open, and I needed to allow manually setting these values without triggering a full rerender of the component.
We can safely revert this. I'll get to it in a future PR.
@@ -34,18 +34,19 @@ function getCellConfiguration( | |||
}; | |||
} | |||
|
|||
export function getCellComponentWithProps( | |||
export function getCellCap( |
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.
Why the shortened name here? Is "CAP" Supposed to be an acronym for "Component And Props"? I would find this naming confusing, especially because "cap" is also a word with its own meaning. I much prefer the more verbose name.
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.
Is "CAP" Supposed to be an acronym for "Component And Props"
Yes, it is. Keeping it verbose made it long, and I thought we could establish the term CAP
in our code base as an acronym for Component And Props
, since we don't use "cap" anywhere else. But I'm fine with keeping it verbose as well.
export interface SheetColumn { | ||
column: Column; | ||
abstractTypeOfColumn: AbstractType; | ||
cellCap: ReturnType<typeof getCellCap>; // CAP refers to ComponentAndProps |
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.
As mentioned in my other comment, I don't like this abbreviation. I'd rather write ComponentAndProps
for better readability.
If there's an important reason for keeping the "CAP" naming convention though, the code comment would be better as a JSDoc comment above the cellCap
property so that it will be semantically associated and appear in editor tooltips elsewhere.
<style lang="scss"> | ||
.filter-entry { | ||
display: flex; | ||
min-width: 560px; |
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.
It seems a lot of this CSS is new. Is there a reason you've used px
instead of em
or rem
, per our standard?
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.
I'm treating most of this css as temporary since we probably might have to re-work some/most of the filtering, sorting and grouping when working on views. I used px to finish this quick. I'm waiting for the UI milestone to work purely on the styles in the entire product.
export let columnId: FilterEntry['columnId'] | undefined; | ||
export let conditionId: FilterEntry['conditionId'] | undefined; | ||
export let value: FilterEntry['value'] | undefined; | ||
export let noOfFilters: number; |
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.
I prefer longer, more readable names without abbreviations like numberOfFilterEntries
or filterEntryQuantity
or filterEntryCount
.
}>(); | ||
|
||
export let entries: FilterEntry[]; | ||
export let processedTableColumnsMap: ProcessedTableColumnMap; |
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.
For code readability and reduced mental friction, I'd ideally like to see consistent pluralization of "columns" across ProcessedTableColumnMap
and processedTableColumnsMap
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.
I agree. Seems like I didn't pay much attention while naming the interface.
Fixes #1072
This PR:
Screen.Recording.2022-05-03.at.3.03.43.AM.mov
Note: This PR does not use the filtering endpoint as mentioned in the ticket. This is because the filtering API lacks information the frontend requires, which we decided was not a good use of time to work on before the alpha. The response is now stubbed in the frontend, similar to Mathesar type configurations. We'll create a separate issue for it to work on after alpha.
I've not added tests for filtering yet. I intend creating new issues and working on them during the cool down phase.
Checklist
Update index.md
).master
branch of the repositoryvisible errors.
Developer Certificate of Origin
Developer Certificate of Origin