feat: add search to Team list

[RODO94]

What does this PR do?

This PR introduces a SearchBox component which pulls in a set of records and search keys, and outputs the results using a setState function.

This is tied into the larger epic here: https://trello.com/c/7av8lsVr/3160-epic-as-an-editor-i-want-to-have-a-way-to-organise-my-flows-so-that-i-can-easily-find-what-im-looking-for

I am using the useSearch hook developed and PoC'd here: #3462

Although I took a slightly different approach to the PoC, due to the way my page was rendering and having to render a list in a parent component.

[github-actions]

Removed vultr server and associated DNS entries

[RODO94]

I wanted there to be a slight delay when processing the results so you don't receive nothing when you start typing. Iterated around doing this around search instead but found this to be the most robust with the other rendering going on. It felt nicer to let search run when things change and then wait to pull the results out of that after the 500ms

[DafyddLlyr]

I hit a similar conclusion with the Search/index.ts component - it would be nice to have debounce be part of the hook but I couldn't find a way to get it to work and render as expected.

I don't think the setup here is quite correct though - this looks like it's setting the records (cheap!) on the debounce vs running the search (expensive).

If you take a look at the file mentioned above I think the order of operations is -

• Form value changes
• formik.handleSubmit() is called
• This debounces the search, based on the pattern
• search(pattern) updates the results variable

If I add a console.log() I see the search firing on each keystroke.

[RODO94]

Not met this so directly, but I have switched this so the search sits in the debounce!

My difficulty was in how to handle the adding of results to the setRecords state dispatch

[DafyddLlyr]

A few things here to take a second look at.

The structure is good, but the implementation is a little unclear. Fundamentally the responsibility of this component is to handle the search term, run the search, and then update it's parent's state.

Something like this will probably get you closer to what you're looking for here -

// When the search is reset, display the full list
useEffect(() => {
  if (!formik.values.pattern) setRecords(records)
}, [formik.values.pattern, setRecords, records]);

// When results are updated, update parent state with the filtered records
useEffect(() => {
  if (!results.length) return;
  const filteredRecords = results.map(result => result.item);
  setRecords(filteredRecords)
}, [results, setRecords]);

[DafyddLlyr]

I hit a similar conclusion with the Search/index.ts component - it would be nice to have debounce be part of the hook but I couldn't find a way to get it to work and render as expected.

I don't think the setup here is quite correct though - this looks like it's setting the records (cheap!) on the debounce vs running the search (expensive).

If you take a look at the file mentioned above I think the order of operations is -

• Form value changes
• formik.handleSubmit() is called
• This debounces the search, based on the pattern
• search(pattern) updates the results variable

If I add a console.log() I see the search firing on each keystroke.

[DafyddLlyr]

Much clearer and simpler 👍 Thanks for picking up the suggested changes so far.

I'm still hitting this issue when running locally -

I'm pretty sure it's as you're describing - we're passing in but also updating records within this component and triggering the loop. Taking a closer look at this now - it might be that the parent needs to keep an original and filtered list, not the search box itself.

I'll post an update here when I have one or maybe we can stay on after standup and debug 👍

[DafyddLlyr]

Sorry - should have been clearer here - I was specifically referring to the border colour that doesn't match.

This is actually inconsistent in a few places in the Editor atm and I'm keen not to introduce any more (cc @ianjon3s)

[DafyddLlyr]

Spinner is great btw 👌

[RODO94]

This originalRecords variable is kept in place to handle behaviour for when we run setRecords(newRecords) for a searched term - this updates records in the parent component and triggers a re-render, but originalRecords is only set on mount and not reset when the components re-render, so it acts as a proper original version of the list.

Records as an immutable prop works differently since it will be updated when the Parent component is re-rendered, like when setRecords(newRecords) is triggered

[ianjon3s]

Good catch on the input border consistency @DafyddLlyr , something I've been meaning to address.

The input borders used in the editor modal are deliberately left lower contrast due to the density and close-proximity of input groupings, and when used on a single/isolated input (especially against a white background) the same border shade is too low-contrast to be effective, hence the darker border shade for the filters setup.

What's needed is a consistent border shade that works in both instances, looking at your examples it seems we already have a style used for data and select inputs that would be a universal fit. I'll go through and update to this in a separate PR.

[DafyddLlyr]

Great!