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

Keep filters option when switching repos #226

Closed
wants to merge 21 commits into from

Conversation

Arif-Khalid
Copy link
Contributor

@Arif-Khalid Arif-Khalid commented Jan 20, 2024

Summary:

Fixes #205

Type of change:

  • ✨ New Feature/ Enhancement

Changes Made:

  • Added checkbox on dialog that opens when selecting a repo
  • If that checkbox is checked when confirming selection, filter selection for status, type, sort, search bar, selected labels and hidden labels are kept
  • Checkbox is not mounted when there is no repo currently selected, i.e., no changes to keep

Screenshots:

  • Before the change
image
  • After the change
image

Proposed Commit Message:

Option to keep filters you have set on repo changes.

No way to keep filters when changing repos.

An option to keep the common filters will be useful for anyone
managing multiple repositories without the hassle of reapplying 
the same filters.

Let's add a checkbox to the change repo dialog allowing 
users to keep their filters.

Checklist:

  • I have tested my changes thoroughly.
  • I have created tests for any new code files created in this PR or provided a link to a issue/PR that addresses this.
  • I have added or modified code comments to improve code readability where necessary.
  • I have updated the project's documentation as necessary.

@Arif-Khalid Arif-Khalid changed the title 205 keep filters Keep filters option when switching repos Jan 20, 2024
Copy link
Collaborator

@gycgabriel gycgabriel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested - The filters are shown but they are not applied after switching the repo
Also, the search bar and the label filters are not persisted.

Comment on lines 26 to 30
/** This copy of the filter is constantly updated when a change in filter is detected */
let currentDropdownFilter: DropdownFilter = { ...DEFAULT_DROPDOWN_FILTER };

/** This is the initial dropdown filter applied when first viewing a new repo */
let initialDropdownFilter: DropdownFilter = { ...DEFAULT_DROPDOWN_FILTER };
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to store both initial and current Dropdown filters?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both are unnecessary in hindsight. Initial dropdown filter variable has been removed.

@Arif-Khalid
Copy link
Contributor Author

Tested - The filters are shown but they are not applied after switching the repo Also, the search bar and the label filters are not persisted.

Committed new changes that fixes functionality for status, type and sort filters.
Labels and issue names are likely always different across repos. Should I continue to work on storing search bar and labels?
If so should I ignore labels that don't exist on the new repo?

@gycgabriel
Copy link
Collaborator

Labels and issue names are likely always different across repos. Should I continue to work on storing search bar and labels?

Actually, for CS2103 projects which is the main use case for WATcher, they will most likely be same or similar. It's up to you if you want to continue working on it or create a separate issue for someone else to pick up.

If so should I ignore labels that don't exist on the new repo?

Yes, drop label selections that don't exist

@Arif-Khalid
Copy link
Contributor Author

Arif-Khalid commented Jan 24, 2024

Labels and issue names are likely always different across repos. Should I continue to work on storing search bar and labels?

Actually, for CS2103 projects which is the main use case for WATcher, they will most likely be same or similar. It's up to you if you want to continue working on it or create a separate issue for someone else to pick up.

If so should I ignore labels that don't exist on the new repo?

Yes, drop label selections that don't exist

I have refactored the code into its own file called FiltersStore.ts and am using a static class to store the filters as they are edited, initialize new repos with previous filter values and clearing the store if filters are not kept.
Current status is that functionality for search, status, type and sort filters are working; Also fixed an oversight that ascending and descending order of sort was not accounted for.
Before I start work on the labels, I would appreciate some feedback on the direction I have taken and if necessary a suggestion for a better, alternative approach.

@Arif-Khalid
Copy link
Contributor Author

Arif-Khalid commented Jan 24, 2024

In hindsight, I think a better approach for consistency would be to have my FiltersStore.ts be the central home of the filters such that all components update and retrieve from FiltersStore. This would negate me having to copy filter changes and will be more developer friendly to understand. What do you think?

Comment on lines +28 to 32
dropdownFilter: DropdownFilter = FiltersStore.getInitialDropdownFilter();

/** The initial search filter value, not updated when search filter is changed */
initialSearchFilter: string = FiltersStore.getInitialSearchFilter();

Copy link
Collaborator

@gycgabriel gycgabriel Jan 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why name it initial?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is named initial because this search filter variable is not updated at all when the user types. Instead this variable is simply used to initialize what is seen by the user at the search bar when they first open a new repo.

@Arif-Khalid
Copy link
Contributor Author

I have updated functionality to include the working logic for storing the status, type, sort, search bar, selected labels and hidden labels when the keep filters option is checked when switching repos. I also encountered a small bug where the DEFAULT_DROPDOWN_FILTER milestones property was being added to when switching repos since the array containing the milestones was passed by reference. My most recent push also fixes this issue.

Copy link
Collaborator

@gycgabriel gycgabriel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm getting errors for structuredClone, is this necessary

ERROR in src/app/shared/issue-tables/FiltersStore.ts:8:58 - error TS2304: Cannot find name 'structuredClone'.

only available in node 17, we're using node 14

@gycgabriel
Copy link
Collaborator

gycgabriel commented Feb 6, 2024

I'm not completely convinced that we need both initial and current variables, since by default it will reset, so why do we have to store the initial state? @CATcher-org/2223s2 what do you think?

@gycgabriel gycgabriel requested a review from a team February 6, 2024 13:17
@Arif-Khalid
Copy link
Contributor Author

Will close this PR to work on #249 as the fix for #205 will be easy after.

@Arif-Khalid Arif-Khalid deleted the 205-keep-filters branch March 4, 2024 04:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

When changing repos, give a way to keep current filters
2 participants