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 27473346421

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