[Search v2.5] [Autocomplete] Highlight autocomplete key and selected value

[lakchote]

See https://docs.google.com/document/d/1o-Hp-tK8Z_BAcE-KRiXQicPH04qNr525EIxlG8J4RxM/edit?tab=t.0#bookmark=id.hy4h27dpoz37

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021864412596340849116
• Upwork Job ID: 1864412596340849116
• Last Price Increase: 2024-12-04

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @289Adam289

[289Adam289]

Hi! According design doc I think this issue should be on hold for Expensify/react-native-live-markdown#439 pr that will allow our parser to be passed as worklet to live markdown.

[ikevin127]

Not overdue, on hold for Expensify/react-native-live-markdown#439.

[ikevin127]

Still on hold for Expensify/react-native-live-markdown#439.

[ikevin127]

Still on hold for Expensify/react-native-live-markdown#439.

[ikevin127]

Still on hold for Expensify/react-native-live-markdown#439.

[lakchote]

Still on hold for Expensify/react-native-live-markdown#439.

Same.

[Kicu]

Issue update

Quick reminder:
we wanted to use https://github.com/Expensify/react-native-live-markdown to implement highlighting in Search autocomplete. I recently discussed the best way to implement this with @tomekzaw who is the author of the PR.
Tomek has done a great deal of work 👏 to allow for the LiveMarkdown component to accept any JS code as parser via a prop.
Now we need to actually implement this in Expensify/App, which will require updating the version of live markdown (and some other packages) and tweaking the current code for RNMarkdownTextInput component.

This should not be a very big change in the code, but as any change it might introduce some small bugs.
In the old implementation of livemarkdown, the ExpensiMark parser was bundled together with the MarkdownTextInput component and was always used.
In the new version of MarkdownTextInput, the component accepts a parser prop, which can be any JS function adhering to correct interface.

I will try to push this forward as smoothly as possible, but we will require some help with testing.

Next steps :

1. I'm testing if the new version works correctly with Expensify locally (<--- we are here)
2. We will want to create a test build, and would need your help in getting some QAs to test it and see if there are no regressions for Composer with ExpensiMark.
3. merge Support custom parsing logic (pass worklet as parser prop) react-native-live-markdown#439 and release new version
4. bump version of react-native-live-markdown in E/App; pass expensiMark as parser for Composer, pass autocompleteParser for SearchRouter
5. Profit $$$ 😉

We will also need to bump reanimated and expensify-common (minor version for both). Thankfully @blazejkustra is already looking at bumping reanimated here: #52024 so this will speed things up.

I will open a draft PR soon for tracking the progress.
Feel free to ask anything. The workletization of parser in LiveMarkdown editor is a feature that multiple people would like to see added to the library. It will give us a lot of freedom, if we want to change how our parsers behave in future.

CC @luacmartins @lakchote @JmillsExpensify @tomekzaw @289Adam289 @SzymczakJ

[blazejkustra]

We will also need to bump reanimated and expensify-common (minor version for both). Thankfully @blazejkustra is already looking at bumping reanimated here: #52024 so this will speed things up.

I created the issue earlier today, would you mind assigning me? @lakchote

[melvin-bot]

@Kicu, @sonialiap, @lakchote, @luacmartins, @ikevin127, @289Adam289 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[melvin-bot]

@Kicu, @sonialiap, @lakchote, @luacmartins, @ikevin127, @289Adam289 Eep! 4 days overdue now. Issues have feelings too...

[Kicu]

we'll be back Jan 7th, and work on this will continue

[melvin-bot]

@Kicu, @sonialiap, @lakchote, @luacmartins, @ikevin127, @289Adam289 Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[luacmartins]

@289Adam289 thanks for the update!

It might be a good time to talk about how we format markdown for different types of keys. Right now, everything recognized by the autocomplete parsers gets the same blue highlight like "user-mention." Should we keep it this way, or try something different for various keys?
Looking forward to your thoughts and any further directions on how to proceed.
cc @luacmartins for thoughts

The doc doesn't mention any specific styles, but the mocks seem to follow the mentions styles, i.e. everything has a blue highlight, except your own mention, which is green. So I think we can keep the same here and have everything blue, except for your own email/display name which should be green.

[melvin-bot]

@Kicu, @sonialiap, @lakchote, @luacmartins, @ikevin127, @289Adam289 10 days overdue. I'm getting more depressed than Marvin.

[luacmartins]

@289Adam289 will resume work once he's back from ooo (maybe on Jan 7th?)

[melvin-bot]

@Kicu, @sonialiap, @lakchote, @luacmartins, @ikevin127, @289Adam289 12 days overdue now... This issue's end is nigh!

[melvin-bot]

This issue has not been updated in over 14 days. @Kicu, @sonialiap, @lakchote, @luacmartins, @ikevin127, @289Adam289 eroding to Weekly issue.

[luacmartins]

This is still a daily. SWM is coming back tomorrow and will resume work here.

[289Adam289]

Update:

Right now iOS and Android work well. Color of a highlight changes to green for current user mention. The only thing left are some cursor position and background alignment issues on web that are being worked on by @BartoszGrajdek in Expensify/react-native-live-markdown#594.
I think we should wait for that LM pr. What do you think @luacmartins?

Current state:
Web:

Screen.Recording.2025-01-08.at.12.42.10.mp4

Android:

Screen.Recording.2025-01-08.at.12.39.39.mp4

iOS:

Screen.Recording.2025-01-08.at.12.32.46.mp4

[luacmartins]

Yea, I agree that we should wait for that PR to fix the alignment. Additionally, gonna tag @Expensify/design for more input on the highlight styles.

[dannymcclain]

I think the highlights are looking pretty good but it would be ideal if we could match them exactly to the styles we use for mention highlights (mainly thinking the border radius and subtle spacing).

Also this might be off topic so feel free to ignore if it is, but will the highlight always happen right away? I think I would expect it to only highlight if we found a legitimate match for the query—but I could be wrong about that. Will let the other designers gut check me there.

[dubielzyk-expensify]

Agree with both of Danny's comments. I also kinda expect it to only show highlight once it's matched, but I don't think it's suuuper critical.

[shawnborton]

Agree with both of those comments.

Also, when you are doing autocomplete on the second item, I would expect the full query to still be there. For example, this is doing two autocompletes in Slack:

But this is what I see from the PR:

[Kicu]

@shawnborton but the top option to pick from in Search is exactly the same query - just like on slack. Do you mean you would like for every single autocomplete item to contain the whole query?
Seems kinda weird to me. What if queries get super long?

[Kicu]

It gets cut away on slack desktop app - not the best UX imo

[shawnborton]

Hmm yeah that's a fair point... though we could potentially right-align those long strings.

Either way, I don't feel too strongly, let's see if others have any strong feelings otherwise we can just go with what you have planned already.

[dannymcclain]

I don't think I feel too strongly about that one 🤔 We could always go with the current plan and see how it feels first.

[dubielzyk-expensify]

Yeah, going with the current plan and adjusting feels right to me given it's hard to predict this one

[289Adam289]

In response to the first @dannymcclain comment, the styles currently used by SearchRouter are the same as those used by Composer input. Adding border radius to the background is a bigger problem that is currently worked on in Expensify.

Regarding the issue of highlighting only when there's a legitimate query match, I think it would be safest to handle that as a follow-up. This PR is already complex, and adding further complications could increase the chance of missing regressions.

[Kicu]

RE: highlighting a mention only when it actually mentions a real login.
This is not something that we are able to easily do in the app right now, and it's a bigger task that Im currently working on in the context of Composer (the main chat input). Here is the issue: #38025

We will make this work in Search input once the above task is completed. We will also make sure that the logic and look of highlights in Search and Composer is the same.

[dannymcclain]

Thanks for the explanation—I'm fine handling that stuff as a follow up since it sounds like this PR is already pretty intense.

[shawnborton]

Yup, that totally works for me too - thanks for clarifying things.