Page MenuHomePhabricator

[8/n] Native Typeahead - Create tooltip component in chat input bar
ClosedPublic

Authored by przemek on Jan 25 2023, 7:29 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM
Unknown Object (File)
Wed, Apr 17, 6:23 AM

Details

Summary

Creating typeahead in ChatInputBar. There is one iOS bug/bad UX described and showed in a thread here: https://linear.app/comm/issue/ENG-2367/typeahead-in-tooltip-for-mentions-for-native

I'm putting up diffs regardless so they can be reviewed, but I can't find a way to fix it.
Adding @ashoat as blocking as the diff contains currently unsolved bug.

Test Plan

Checked if app builds.
Video android:

Video iOS (showing bug with cursor not moving past name)

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

ashoat added inline comments.
native/chat/chat-input-bar.react.js
478–517 ↗(On Diff #21319)

Not familiar with this logic, defer to others

Personally find the ternary messy, feels like it would be cleaner to have an if (typeaheadRegexMatches) { branch, or maybe move all of this to a function so you could return null whenever you need to, and otherwise just proceed with normal function calls

tomek requested changes to this revision.Jan 30 2023, 3:52 AM

It might be a good idea to check how this code performs on a slower Android device when there are a lot of matches and a text is long. It seems like memoization could be a good idea here - in class components we can achieve that by using createSelector, chat-thread-list contains an example.
If the performance is ok, we don't have to complicate the code.

native/chat/chat-input-bar.react.js
478–481 ↗(On Diff #21532)

How about the case where selection start is different than its end?

478–488 ↗(On Diff #21532)

We can optimize this code. There's no point in slicing the string when we're not going to check if it matches the regex.

This revision now requires changes to proceed.Jan 30 2023, 3:52 AM
przemek marked 2 inline comments as done.

I've tested the app in simulator, which is not ideal, but probably less time consuming than dealign with physcial build right now, and the performance seems identical using master branch, or branch with typeahead feature. I've pasted huge message into chat input bar, and hasn't spotted any lag when it comes to typeahead showing or updating.

native/chat/chat-input-bar.react.js
478–481 ↗(On Diff #21532)

It might be a bit inexplicit, but this test:

/\s/.test(this.state.text[this.state.selection.start])

failed, when the first selected character was non-whitespace.
I'm not sure what effect we want to achieve with selection near @ symbol.
For now I'll add condition so we only display typeahead when start === end and create linear task for that

small fix - the condition was wrong

tomek requested changes to this revision.Jan 31 2023, 5:23 AM
tomek added inline comments.
native/chat/chat-input-bar.react.js
479–486 ↗(On Diff #21665)

This ternary is complicated - could you replace this with an if? Probably most of the ternaries from here should be replaced, according to https://www.notion.so/commapp/Use-ternary-conditionals-sparingly-f4ba44a10259403592a1d15440a9847e

This revision now requires changes to proceed.Jan 31 2023, 5:23 AM
native/chat/chat-input-bar.react.js
479–486 ↗(On Diff #21665)

As I pointed out earlier, I think this can mostly be replaced with a if (typeaheadRegexMatches) {

Mostly refactor. Respond to reviewers.

ashoat requested changes to this revision.Jan 31 2023, 12:06 PM
ashoat added inline comments.
native/chat/chat-input-bar.react.js
557–582 ↗(On Diff #21693)

Combine these, reduce conditionals

This revision now requires changes to proceed.Jan 31 2023, 12:06 PM

Combined conditionals. That logic should be refactoed into seperate functions as it's quire similar to the web counterpart anyway. I've created the task for that: https://linear.app/comm/issue/ENG-2891/refactor-some-of-the-native-typeahead-creation-logic-and-make-web
I'd rather do it after native typeahead is landed as it has higher prio.

Readability is getting a lot better. Please address inline comment before landing

native/chat/chat-input-bar.react.js
534–555 ↗(On Diff #21727)

These should be combined into if + else if

native/chat/chat-input-bar.react.js
545–553 ↗(On Diff #21734)

only place where androidPreviousText is used

ashoat requested changes to this revision.Feb 1 2023, 10:33 AM

You changed behavior in the last update. Previously if both conditions were valid, we would "default" to the this.androidPreviousText condition. Now we're "defaulting" to the condition. Is this change intentional, and does it potentially introduce any issues?

This revision now requires changes to proceed.Feb 1 2023, 10:33 AM

My above comment needs to be addressed before landing (maybe by switching order of conditions), but switching to an accept so it stays on @tomek's queue

This revision now requires review to proceed.Feb 1 2023, 10:34 AM
tomek requested changes to this revision.Feb 2 2023, 5:21 AM

Now we're "defaulting" to the condition. Is this change intentional, and does it potentially introduce any issues?

After simplifying the condition it seems like the inverted logic shouldn't work properly.

@przemek please remember to test this thoroughly after the conditions are changed.

native/chat/chat-input-bar.react.js
534–553 ↗(On Diff #21734)

It seems like this can be significantly simplified by extracting the common part. This will also default to the Android text.

This revision now requires changes to proceed.Feb 2 2023, 5:21 AM

Moved the logic to separate function. It's places in lib, as it should also be used in web. We have task for that: https://linear.app/comm/issue/ENG-2891/refactor-some-of-the-native-typeahead-creation-logic-and-make-web
I've tested a lot and it works we default to using state, if values in class fields are null.

This revision is now accepted and ready to land.Feb 2 2023, 9:26 AM