Addressed comments

Responded to inlines and fixed code.

Idea changed a bit. Now all state regarding typeahead overlay is gatherd in one object.
It will keep callback accept and close so they can be called outside of overlay to perform actions on it.

Sorry, morning brain fart.
Yeah, disabled doesn't need to be there.

Using classNames.

As @ashoat suggested, I added all <button> props.

Changed mouseOver to mouseMove so it triggers correctly.
It begs a questions whether I should even try to use generic Component and not plain html tag, if use case is so custom.

deleted comment

Fixed readonlys

Responded to suggestions.

Responded to suggestions.

We can't use flex: 1, as it sets flex-basis: 0%, and apparently we need some explicit pixel value.
I set it to flex-basis: 120px, so it can never be shrinked to size shorter then two elements.
Should rarely happen, as nobody expects webpage to wrok propery with 300px of window height.

Fixed. Changes I've made in previous diff were.. far fetched to say the least. Minor css fix did the job!

Realized too late that it also should be put inside useMemo.

Responded to inlines and fixed code.

Fixed props.

Had some problems with our git workflow and left that as an artifact. Sorry for that, fixed now.

Responded to inlines and fixed code.

Rebase

Renaming function

Yes, ff we swap textarea to contentEditable and keep saving caret position in context we keep the feature of saving its position when changing threads. It would require some changes, but nothing to serious.

I think saving caret position is not strictly necessary now. I preferred to use it, as we treat textarea as controlled component, so we want to control it via state we can update use.
Without saving cursor position:

1. We would need to rely on selection start and end from textarea element. With editable div, we would rely on global Selection object.
2. We wouldn't get that nice-to-have saving cursor position when jumping between threads

Hi @ashoat, I spent some time looking and tried my best to find some quality source , but couldn't find any. Most are old, low quality posts.
I think your's and Tomek's experience and opinions would be more valuable than those.
I see two possible solutions here:

1. We go with current solution based on textarea.
2. We spend some time refactoring ChatInputBar to use div with contentEditable enabled. That would require extra work as we would need to handle some more things manually.

No, unfortunately it does not, because of this:

After some research I was not able to find any site explicitly telling that it can't be done in another way, but the only two feasible solutions I see is:

1. Go with textarea and dummy div.
2. Go with custom textarea(div) and use window.getSelection()

After further reading on above solution I discovered one gimmick. We would either need to implement custom textarea i.e. we would need div(which we probably don't want) as window.getSelection() doesn't trigger correctly in textareas, because
they provide custom API (https://html.spec.whatwg.org/#textFieldSelection).

Yeah, sorry for that. I thought I browsed through most of it and couldn't find anything interesting, that would differ significantly from what I've done.
This solution though seems good and much clearer than creating dummy div:
https://javascript.plainenglish.io/how-to-find-the-caret-inside-a-contenteditable-element-955a5ad9bf81
https://codesandbox.io/s/caret-coordinates-index-contenteditable-9tq3o?from-embed=&file=/src/index.js:577-591

Done. It would be nice to have unit tests covering utility functions like that. Probably will mention it during today's monthly planning.

Responded to inlines

Initially I got idea from this site: https://jh3y.medium.com/how-to-where-s-the-caret-getting-the-xy-position-of-the-caret-a24ba372990a.
I browsed through available resources and what people suggested was either that, or even more hacky solution using canvas. Some of solutions only gave offset of caret in characters count, but that's insufficient for us, as we need x,y position of caret in textarea.
Later on I found npm package that does it in a similar way:
https://github.com/component/textarea-caret-position

Fixed button import...
Fallen into a trap of VSCode automatically importing Button as button.

Responded to inlines, fixed where neccessary.

Responded to inlines, fixed code and tested if it didn't break renders.

(Did we take a look at any prior work for this? This seems like the sort of problem that others have probably run into before and there might be established or simpler solutions we could work off of?)

Added theme.css changes as well. Sorry for missing that.