Putting this one up first, as it's the "base case". iOS basically has to do everything that Android does.
Depends on D6641
Details
Details
- Tested both iOS and Android
- Made sure there was no flicker
- Tested @-tag in both middle and end of text
- Tested moving cursor after selecting @-tag
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| native/components/selectable-text-input.react.js | ||
|---|---|---|
| 37 ↗ | (On Diff #22170) | I should remove this comment – we *are* doing something |
| native/components/selectable-text-input.react.js | ||
|---|---|---|
| 60–62 ↗ | (On Diff #22170) | We can use a shorthand |
| 73–75 ↗ | (On Diff #22170) | We can consider destructuring selection out of rest props because we're always overriding it here. const {
clearableTextInputRef,
onUpdateSyncedSelectionData,
onSelectionChange,
selection,
...rest
} = props; |
| native/components/selectable-text-input.react.js | ||
|---|---|---|
| 60 ↗ | (On Diff #22252) | It looks like we're not using onSelection when creating this component in ChatInputBar Is it there to keep compatibility with TextInput API (i.e. someone sometime in future may want to use that normal callback) or is there something I missed? |
| native/components/selectable-text-input.react.js | ||
|---|---|---|
| 60 ↗ | (On Diff #22252) | Yes, we don't want to break compatibility. You can see we forward all TextInput props... SelectableTextInput is meant as a drop-in replacement for TextInput that addresses issues with selectable text |