Update. After changes to :hover behaviour in the newest revision of the previous diff, there are no longer visual changes in the thread composer.

Update

Update. Changed typing and re-added the transparent border. To keep all the properties dealing with border in sync I have added two css variables. Otherwise if someone wanted to change the border width or radius there would subtle visual bugs.

Updated to the new method. There's a slight visual change because now instead of using predefined colors for :hover colors we are using the filter property. I have tried to select the brightness values so that the changes are minimal (before/after):

I have talked with @tomek about this and we have figured out a solution without the z-index. I will update this diff shortly.

Sorry, I should have explained more and not just dropped the code in the comment.

Without the z-index the ::before pseudo-element covers the Button children and I couldn't find a way to make it work without it.

Are you sure about this? Can you perhaps link some StackOverflow or GitHub discussions that talk about this? I wonder what would happen if you dynamically (in JS) render a <style> tag

Here and here. I couldn't find anything that explicitly states that it's impossible but it seems like it. I tried just including ':hover': {color: 'red'} in the inline styles but it didn't work for me.
I think rendering <style> is one of the workarounds mentioned in the linked posts but it doesn't seem that great to me.

After talking with @ashoat it seems like the previous changes are not the best solution. In particular they don't support hover animation for all colors and only for the predefined success and danger.

Abandoning the diff in favour of other solutions.

I tried to be as thorough as I could while testing, I will probably take another look at all the buttons before landing.

Added text-transform: uppercase back. This update also fixes two bugs that introduce changes to visuals so I'm requesting a review again.

• the RETRY? button didn't change color depending on chat color (I didn't notice it before because I was testing on a blue chat)
• The DELIVERY FAILED text was black so it wasn't visible. I wanted to create a task for this later, but while adding text-transform back I think it made sense to do this here instead of a one-line change later.

Please see the summary for images.

Kind of agree, although I also agree with @atul that the green tint is a bit too dark.

Memoize buttonColor

Remove different hover behaviour.

According to this article it's better for screen-readers (and it's better for a few other reasons but I don't think they are applicable to our example). I think we should change it back to text-transform.

Cleaned up css.

Cleaned up css.

Removed the text-transform: uppercase. Fixed a bug with buttons in thread composer and this resulted in a slight change in visuals (see the updated summary). But that could be easily changed if it's undesirable.

Thanks for the help, I think it should be visible now!

Rename variants and buttonColor prop.

Sorry, I should have caught that!

There's a css block:

div.failedSend {
  text-transform: uppercase;
  (...)
}

that previously applied to the "Retry?", but now that we use Button it had to be copied to retryButtonText. So I just kept the old behaviour, but I don't see any reason why we couldn't just use RETRY? (and <span>DELIVERY FAILED.</span>).

In D5321#157310, @atul wrote:

Do you think it would be clearer if we renamed primary to filled and secondary to outline to help distinguish the two variants?

Shorter lines

Rebase

Made requested changes, rebase

Use threadIsSidebar, rebase

Rebase

I can confirm that this fixes the issue for me!

Rebase, tested variants mentioned by ashoat

After 1-1 with Ashoat most changes here are not applicable, so I'm closing this and creating another stack.

Rebase

Added comment

Rebase on master

Rebase

Added notification id to the logs on android and ios.

Rebase on master, run the tests instead of just compiling

Additional rename, rebase

Added explicit return in response to review. Also based on the notes about .length() which makes the notification immutable, added a defensive _cloneDeep before checking the notification size without the messageInfos.

Yes, I've checked. I will amend the test plan right now.

According to this stackoverflow comment (which isn't about if constexpr but still applies) compilers can backport useful features from newer versions of the standard to the previous versions if they are purely additive and wouldn't change the meaning of the code. This is probably what's happening here. There's a Wno-C++17-extensions flag if we want to disable this behavior (although we depend on c++17 in a few other places, as noted in the previous comment).

Update, removed some duplicate code.
I had to use if constexpr to differentiate between void and non-void instantiations of runSyncOrThrowJSError, because promise<void>::set_value takes no arguments so we can't call set_value(task()) (even if task returns void).
There's a warning while building android version:

warning: constexpr if is a C++17 extension [-Wc++17-extensions]

but there are already similar warnings about other code in this file:

warning: decomposition declarations are a C++17 extension [-Wc++17-extensions]
for (const auto &[message, media] : messagesVector) {

and it compiles on both android and ios.
There are ways to avoid using c++17 features but they would be much uglier.