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

Add type based filtering, improve filtering UX #1341

Merged
merged 15 commits into from
May 3, 2022
Merged

Conversation

pavish
Copy link
Member

@pavish pavish commented May 2, 2022

Fixes #1072

This PR:

  • Updates filtering to use latest request structure
  • Adds type specific filtering options
  • Adds type based filter inputs
  • Optimizes Cell performance by calculating abstract type info and input info at a higher layer
  • Improves filtering UX and error states
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

  • My pull request has a descriptive title (not a vague title like Update index.md).
  • My pull request targets the master branch of the repository
  • My commit messages follow best practices.
  • My code follows the established code style of the repository.
  • I added tests for the changes I made (if applicable).
  • I added or updated documentation (if applicable).
  • I tried running the project locally and verified that there are no
    visible errors.

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

@pavish pavish requested review from a team and seancolsen and removed request for a team May 2, 2022 21:46
@pavish pavish added the pr-status: review A PR awaiting review label May 2, 2022
@pavish pavish requested review from a team and dmos62 and removed request for a team May 2, 2022 22:05
@codecov-commenter
Copy link

codecov-commenter commented May 2, 2022

Codecov Report

Merging #1341 (a06197a) into master (73f785b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1341   +/-   ##
=======================================
  Coverage   93.71%   93.71%           
=======================================
  Files         114      114           
  Lines        4439     4439           
=======================================
  Hits         4160     4160           
  Misses        279      279           
Flag Coverage Δ
pytest-backend 93.71% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73f785b...a06197a. Read the comment docs.

Copy link
Contributor

@seancolsen seancolsen left a 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;
Copy link
Contributor

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).

Copy link
Member Author

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(
Copy link
Contributor

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.

Copy link
Member Author

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
Copy link
Contributor

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;
Copy link
Contributor

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?

Copy link
Member Author

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;
Copy link
Contributor

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;
Copy link
Contributor

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

Copy link
Member Author

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.

@seancolsen seancolsen merged commit 275240a into master May 3, 2022
@seancolsen seancolsen deleted the filtering_1072 branch May 3, 2022 16:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr-status: review A PR awaiting review
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

Frontend implementation for type specific filtering options
3 participants