adds a search box to the toolbar featureflag list

[pauldambra]

Changes

When there are lots of feature flags it is hard to find flags in the toolbar feature flags list.

This adds a search box that filters the list of flags

How did you test this code?

by running it locally

attempting to write a test case for the feature flag logic led to a test runner error

/Users/pauldambra/github/posthog/node_modules/query-selector-shadow-dom/src/querySelectorDeep.js:6
    import { normalizeSelector } from './normalize';
    ^^^^^^

    SyntaxError: Cannot use import statement outside a module

So I didn't write any tests

[mariusandra]

Love the addition of this, though I'd turn the logic around. Comment inline.

[mariusandra]

• This isHiddenBySearch has a o(n^2) issue that might get annoying if you have a thousand flags on a slow system. If you want to improve this, make searchMatches return a Set instead.

• However I'd use a different pattern altogether. Make a selector filteredFlags, and filter the userFlags through it. You'll end up with a smaller array that you'll loop over in the component instead. There is some value in not removing the element from the DOM and just hiding it with CSS, but I'm not sure it outweighs the added complexity here.

[pauldambra]

Ah, I wondered if it was that! 🙌

[mariusandra]

I patched the issue jest had with this logic. JS can be fun 😅.

I'd still like you to rework the selectors here in the way I suggested before.

Imagine data flowing through the app as a river, starting with bytes on disk, ending with your user's eyeballs:

There's a way to make this river flow smoothly through Kea (in a way some would call functional programming), but the current implementation adds a few pumps and loops to move the water around.

Basically, instead of using a lookup table to filter results, make the lookup table itself the filtered results... 🤔

[pauldambra]

@mariusandra I thought this was what you were suggesting. Is it worth syncing up if it isn't cos I don't understand if so :)

[mariusandra]

Move the Fuse logic into filteredFlags. There's no need to hold in memory a separate list of matching names of flags.

Basically, change this:

userFlags 
  |-> userFlagsWithCalculatedInfo \
  \-> flagNames                   |-> filteredFlags
       ^   \-> searchMatches------/
searchFilter

into this:

userFlags & searhFilter -> userFlagsWithCalculatedInfo -> filteredFlags

[mariusandra]

Smooth laminar data flow, no loops ➰

[mariusandra]

Hm, again, why are you filtering out names, sending them to Fuse, and later using a set-based lookup table in yet another filter? Just send the entire flags array to fuse and let it remove those where the name doesn't match.

[pauldambra]

Just send the entire flags array to fuse and let it remove those where the name doesn't match.

Ah, ok, went away and read the Fuse docs. I think I understand now

[mariusandra]

This looks good now! Feel free to do something with the tests as well, and then merge it in.

[mariusandra]

This issue is very closely related though... Copying the skittish from here should be an easy fix to whoever wants to take this on
#6202