feat(importAccount): typeahead support using searchindex

[aewing]

What this PR does 📖
Implements a typeahead filter on the import account page

Which issue(s) this PR fixes 🔨
AP-322

Special notes for reviewers 🗒️
Made some changes to the active item logic:

• Only one item can be active, mouse and keyboard will now take focus from one another
• Pressing enter immediately after typing will now select the first match in the list

Additional comments 🎤
extends #2179

[netlify]

✅ Yeeeehaw, deploy preview is ready!

Name	Link
🔨 Latest commit	96ccc75
🔍 Latest deploy log	https://app.netlify.com/sites/adoring-edison-dbcef8/deploys/62435e3796ef4e000825764b
😎 Deploy Preview	https://deploy-preview-2422--adoring-edison-dbcef8.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[stavares843]

/rebase

[stavares843]

@aewing the other PR was merged, is this one still draft?

[phillsatellite]

Tested: functionality works great but the list seems to be endless now and user cannot scroll to the bottom of it

import.3.mov

[stavares843]

Gravacao.do.ecra.2022-03-24.as.13.50.54.mov

this branch vs dev

import account is broken on this branch, video above

if you copy paste a whole key, only pastes the first word

[aewing]

Thanks for finding these. Addressing these issues this morning, will have some updates soon.

[stavares843]

this is reverting this modification we did - #1499

basically, the first keyword shouldn't be highlighted

this branch

dev

[aewing]

this is reverting this modification we did - #1499

basically, the first keyword shouldn't be highlighted

I can revert this change, but I found this to be flow breaking personally. I might save a few keypresses by having the item selected automatically and being able to press enter to continue to the next word (which is what I am accustomed to as a user with typeahead inputs). Reviewing the linked ticket, there isn't much detail about the 'why' behind this, so I thought perhaps it was related to a bug with the dual states of mouse hover and keyboard which have been resolved.

[aewing]

@phillsatellite can you provider clarity on what we were actually solving for with #1499?

[stavares843]

basically, the first word on that PR was always highlighted, and Alex fix that

if you go to dev, the first word is not highlighted

but on this PR, was being highlighted again

basically we don't want words highlights when user is still searching unless user is hovering on those

[stavares843]

for speed's sake, not against in not reverting the above

cc @WanderingHogan

[aewing]

basically, the first word on that PR was always highlighted, and Alex fix that

if you go to dev, the first word is not highlighted

but on this PR, was being highlighted again

basically we don't want words highlights when user is still searching unless user is hovering on those

Yea, I see what you're saying. I'm just trying to understand why we would not want this behavior, as it is the default behavior for as-you-type/typeahead components everywhere. I will revert the change today, but thought it worth having the discussion because the default selection feels right to me as a user.

[WanderingHogan]

I think this is good to go in if the functionality is there. The typeahead got very complex and it didn't need to be. We shouldn't add overrides for everything and try to steer towards using things without a million overrides

[stavares843]

sounds good 🔨

[WanderingHogan]

🚀 🌔