Migrate graders_manager.jsx to React Table V8

[mrafie1]

Proposed Changes

(Describe your changes here. Also describe the motivation for your changes: what problem do they solve, or how do they improve the application or codebase? If this pull request fixes an open issue, use a keyword to link this pull request to the issue.)

• Added new filter component under table folder to include case sensitive filtering along side searching: case_sensitive_search_filter
  • Updated filter.jsx to allow this component to be displayed when filterVariant: "case-sensitive-text" is used
• Updated search_filter.jsx aria-label definition
  • Previously used I18n.t("table.search")
  • Now uses column.columnDef.header
  • Reasoning: When migrating GradersTable to v8, the full_name column uses search_filter.jsx for its search bar component. However, previous tests for graders_manager.tsx expected a search bar with the qualities: {name: ${I18n.t("search")} Name. With the previous definition, only the aria-label ${I18n.t("search")} appears when running screen.debug(). Mimicking the previous implementation for caseSensitiveTextFilter in table_helpers.jsx, allows all frontend tests to run and fixes the missing information in the aria-label.
• Migrated GradersTable and GroupsTable to React Table V8
  • Added functions that were previously present in V6 implementation: getSelectedRows() and resetSelection()
  • Mimicked the previous implementation defining of columns
  • Mimicked https://github.com/MarkUsProject/Markus/pull/7826 props input to <Table>
  • GradersTable
    • Added ComponentDidUpdate function so that it updates the state attribute columnFilters when toggling display inactive graders checkbox
  • GroupsTable
    • Edited ComponentDidUpdate function so that it updates the state attribute columnFilters when toggling display inactive groups checkbox
    • Added isCaseSensitive attribute to state
    • Passed in toggleCaseSensitivity function to group_name column's meta-section to allow the filter component to update caseSensitivity.

Screenshots of your changes (if applicable)

Before

After

Associated documentation repository pull request (if applicable)

Type of Change

(Write an X or a brief description next to the type or types that best describe your changes.)

Type	Applies?
🚨 Breaking change (fix or feature that would cause existing functionality to change)
✨ New feature (non-breaking change that adds functionality)
🐛 Bug fix (non-breaking change that fixes an issue)
🎨 User interface change (change to user interface; provide screenshots)
♻️ Refactoring (internal change to codebase, without changing functionality)	x
🚦 Test update (change that only adds or modifies tests)
📦 Dependency update (change that updates a dependency)
🔧 Internal (change that only affects developers or continuous integration)

Checklist

(Complete each of the following items for your pull request. Indicate that you have completed an item by changing the [ ] into a [x] in the raw text, or by clicking on the checkbox in the rendered description on GitHub.)

Before opening your pull request:

• I have performed a self-review of my changes.
  • Check that all changed files included in this pull request are intentional changes.
  • Check that all changes are relevant to the purpose of this pull request, as described above.
• I have added tests for my changes, if applicable.
  • This is required for all bug fixes and new features.
• I have updated the project documentation, if applicable.
  • This is required for new features.
• If this is my first contribution, I have added myself to the list of contributors.

After opening your pull request:

• I have updated the project Changelog (this is required for all changes).
• I have verified that the pre-commit.ci checks have passed.
• I have verified that the CI tests have passed.
• I have reviewed the test coverage changes reported by Coveralls.
• I have requested a review from a project maintainer.

Questions and Comments

(Include any questions or comments you have regarding your changes.)

Small Note:

• For coveralls
  • textFilter is no longer being used in this file, we are using filter.jsx instead
  • Am I good to go with the coverage?

Very important question:

• In the group table, the section and criteria_coverage_count columns are controlled by props being passed in.
• Specifically, this.props.showCoverage and this.props.showSections.
• However, putting these variables into the <Table> component initialState definition means that they cannot change, even if the props being passed in are changing (Correct me if I'm wrong).
• I've followed Lizzie's implementation, where she just has the column shown by default.
• I want to know if this is the best course of action. If not, what should I change?

Please feel free to ask about a specific component. I ended up removing many of the previous functions to make my implementation more similar to Lizzie's and to 'mock' the functionality of the previous implementation.

Am I good to start migrating the Annotations table? I'm kind of interested in pursuing another part of the codebase/doing something different. I'll let you know if I have anything specific in mind.

[coveralls]

Coverage Report for CI Build 27581324586

Coverage decreased (-0.05%) to 90.162%

Details

• Coverage decreased (-0.05%) from the base build.
• Patch coverage: 24 uncovered changes across 1 file (47 of 71 lines covered, 66.2%).
• 4 coverage regressions across 2 files.

Uncovered Changes

File	Changed	Covered	%
app/javascript/Components/graders_manager.jsx	61	37	60.66%
Total (3 files)	71	47	66.2%

Coverage Regressions

4 previously-covered lines in 2 files lost coverage.

File	Lines Losing Coverage	Coverage
app/javascript/Components/graders_manager.jsx	2	43.17%
app/javascript/Components/Helpers/table_helpers.jsx	2	33.94%

---

Coverage Stats

Relevant Lines:	50301
Covered Lines:	46357
Line Coverage:	92.16%
Relevant Branches:	2310
Covered Branches:	1078
Branch Coverage:	46.67%
Branches in Coverage %:	Yes
Coverage Strength:	126.48 hits per line

---

💛 - Coveralls

[david-yz-liu]

@mrafie1 nice work, I left a few inline comments. Also, please make sure to convert the criteria table in this view as well.

You don't need to worry about test coverage for textFilter.

[david-yz-liu]

It's fine to duplicate the caseSensitiveTextFilter component for React table v6, but you need to fully duplicate the logic. In particular, there is no need to store "case sensitive" state in the parent component. Instead, column.setFilterValue should pass an object (keys filterValue, caseSensitive) which are then used by the corresponding filter. This plays the same role as the onChange handler in the existing component.

For more information see #7938.

[mrafie1]

Encountered many issues relating to Git, moved all of my changes to new PR