feat(MobileSearch): Updated mobile search to the new algolia view

[kotva006]

Summary of changes

Replaced the mobile search input with the new algolia search component.
Functionally nothing should have changed from the users point of view

Asana Ticket: AutocompleteJS v1.0 | Mobile header

---

General checks

• Are the changes organized into self-contained commits with descriptive and well-formatted commit messages? This is a good practice that can facilitate easier reviews.
• Testing. Do the changes include relevant passing updates to tests? This includes updating screenshots. Preferably tests are run locally to verify that there are no test failures created by these changes, before opening a PR.
• Tech debt. Have you checked for tech debt you can address in the area you're working in? This can be a good time to address small issues, or create Asana tickets for larger issues.

New UI, or substantial UI changes

• Cross-browser compatibility is less of an issue now that we're no longer supporting IE, but changes still need to work as expected in Safari, Chrome, and Firefox.
• Are interactive elements accessible? This includes at minimum having relevant keyboard interactions and visible focus, but can also include verification with screen reader testing.
• Other accessibility checks such as sufficient color constrast, or whether the layout holds up at 200% zoom level.

New endpoints, or non-trivial changes to current endpoints

• Have we load-tested any new pages or internal API endpoints that will receive significant traffic? See load testing docs
• If this change involves routes, does it work correctly with pertinent "unusual" routes such as the combined Green Line, Silver Line, Foxboro commuter rail, and single-direction bus routes like the 170?

[thecristen]

let's maintain the "header-mobile" id here

[thecristen]

Thanks for upload to dev-blue. Has interacting with it there worked ok on your phone?

I tried on my iPhone and it was mostly fine, I noticed a few things:

1. This code makes it so that opening the search menu automatically brings your focus to the search input. I'm guessing the selector might need to be updated to maintain that feature here.
2. The old version changes the header background color to a darker blue when the search gets opened. That code doesn't seem to work equally well with the new search bar - it reverts back to the light blue when there's a query with too few characters to render the search results.

3. After I click a result (or after I press enter) and get taken to the new page, I can't seem to scroll.... Not sure if that's a consistent thing or not though.

[thecristen]

1. The custom styles used in the header desktop search bar don't automatically get applied here, did you see it look different? Anyway, adding the #header-mobile selector here should do it.
2. After I click a result and get taken to the new page, I am unable to scroll the page. Can you look into this? Might need to use the Simulator if it's not happening on all phones.

[kotva006]

1. here

1. The custom styles used in the header desktop search bar don't automatically get applied here, did you see it look different? Anyway, adding the #header-mobile selector here should do it.
2. After I click a result and get taken to the new page, I am unable to scroll the page. Can you look into this? Might need to use the Simulator if it's not happening on all phones.

1. I added the selector
2. On both chrome and safari the mobile screens both let me scroll after clicking a stop in the search

[thecristen]

@kotva006

1. Thanks, looks reasonable now!
2. Sorry yeah, it might not come through in the desktop browsers, but I am able to simulate it via the Simulator app on an iPhone 14 and an iPhone SE (both for dev-blue and with localhost on your branch).

[thecristen]

Please QA against prod or dev -- the tablet view needs to maintain disabled scrolling of the page body.

[thecristen]

📱 I think it'll work, thanks! Can you update to the latest master / resolve the conflict so the tests can run?