[DT-777] Filter by participant count

[rjohanek]

Addresses

Jira Ticket: https://broadworkbench.atlassian.net/browse/DT-777

Summary

Adds a filter for participant size

DatasetSearchTable:

• generalize the filter handler to work for non-Array filters
• generalize the numFiltersSelected method to work for non-Array filters
• update assembleFullQuery to include range chunk
• rename isFiltered to isFilteredArray because it is only used for array filters
• remove unused arguments to filterHandler and unused prop to DatasetFilterList

DatasetFilterList

• add new filter range constant
• add new filter to the filter list

Testing

Unit tests
Note: cy.clock() is needed to mock the clock for debounced calls

Visual

Screen.Recording.2024-11-21.at.9.59.40.AM.mov

---

Have you read Terra's Contributing Guide lately? If not, do that first.

• Label PR with a Jira ticket number and include a link to the ticket
• Label PR with a security risk modifier [no, low, medium, high]
• PR describes scope of changes
• Get a minimum of one thumbs worth of review, preferably two if enough team members are available
• Get PO sign-off for all non-trivial UI or workflow changes
• Verify all tests go green
• Test this change deployed correctly and works on dev environment after deployment

[pshapiro4broad]

Looks OK, just a few misc comments.

[pshapiro4broad]

I would combine an if after an else here

Suggested change

	} else {
	if (filters[category]) {
	} else if (filters[category]) {

[fboulnois]

I like most of @pshapiro4broad 's suggestions! The only one I'm not sure about is the filterHandler refactor.

[rjohanek]

unused

[pshapiro4broad]

Looks good, glad to see that the flaky tests have been fixed

[pshapiro4broad]

For a single line lambda, you can omit the { return }

Suggested change

	const anyFiltersSelected = (filters) => {
	return Object.values(filters).some((filter) => {
	const anyFiltersSelected = (filters) =>
	Object.values(filters).some((filter) => {

I know in terra-ui this was the standard, not sure if duos-ui has an opinion about this.

[pshapiro4broad]

Is it required that searchIndex1 must be different than searchIndex2 in the other test? I would expect the alias names to be independent across tests so the same name could be used for both.

[rjohanek]

good question, no I don't think so I just changed them to detangle as part of the debugging effort but I can change them back now

[rushtong]

I can see that this test does pass, but I'm confused as to what the .all part of this alias selector is doing and where it is defined.

[rushtong]

I think I found why it is undocumented:

• Document @alias.all and @alias.2 cypress-io/cypress-documentation#1573
• [WIP] Enable aliases names to contain the dot character cypress-io/cypress#3929 (comment)

Since .all is experimental, I would recommend looking into a different approach to this specific case.

[rushtong]

Here's another approach, less concise, but uses documented cypress features:

      let count = 0;
      cy.wait('@searchIndex').then((response) => {
        expect(response.response.body[0]).to.equal('filtered');
        count++;
      });
      cy.get('@searchIndex').then(() => {
        expect(count).to.equal(1);
      });

[rushtong]

Cypress recommends not chaining calls after clear. It's a little more verbose, but safer to:

      const range = cy.get('#participantCountMax-range-input');
      range.clear();
      range.type('50');

[rushtong]

Cypress recommends that there be a clock command that precedes the tick command: https://docs.cypress.io/api/commands/tick

[rjohanek]

I use the clock command in the before each method, but I could move it into each individual test

[rushtong]

Thank you, I did miss that. No need if it's there, that should cover it.

[rushtong]

See comments inline, looks good, thank you 👍🏽