In D6121#184564, @ginsu wrote:

In this diff we should update redux-types by setting a payload type of started action

D5769 should address this, but please let me know if I missed anything

Could you also add some tests where number is negative?

Seems reasonable, but I'm really far from being an expert.

Accepting, but according to the comments some additional work may be necessary.

We have to make sure our types are in sync with the code. In this diff we should update redux-types by setting a payload type of started action - it would be great if Flow could catch this.

Checked the rest of the stack and it doesn't seem like incrementing the id is handled. We should extend local-id-reducer to react on appropriate action.

We also need to increase the next local id when a message is sent, but I guess it is handled later in the stack.

It sounds a little strange to say that reaction message is composable, but it shares a lot of properties with other composable message types, so I think it makes sense to include it in this set.

I don't think that adding a flag to a constructor is a good idea. Calling migrate from constructor gives us a really strong guarantee that if an instance is created it will have all the migrations applied. By introducing a flag we would allow having partially initialized object - now all the instance methods would have to check how far the initialization went and if the can safely execute.

Why do you move it?

It seems like this isn't typeahead-specific. Can we move it to a different place, probably in lib?

Nice!

In D6086#183275, @atul wrote:

In D6086#182693, @tomek wrote:

Sounds reasonable. But now I'm wondering if introducing new action was a good idea. Maybe dispatching the old action (possibly with a new field e.g. type) might be easier? I don't think we should change it now, though.

My understanding is that there's usually a 1:1 relationship between endpoints and actions? There could definitely be "1 action to many endpoints" relationships in the codebase, but I didn't look too hard.

Use debounce

For me the 1st option looks the best as the margin of header is consistent with other elements.

In D6099#182910, @marcin wrote:

In D6099#182857, @tomek wrote:

Could you share a screenshot of the component without the password prompt?

For SIWE account (does not prompt for password)

For conventional account

Could you share a screenshot of the component without the password prompt?

It might be a good idea to add a link to the fork in the summary.

Will be syncing with @tomek about landing these changes since he is also working in tooltip-utils for the copy button on the tooltip.

The only thing we should synchronize is the ordering of the buttons. Other than that the diffs could be landed in any order and there shouldn't be significant conflicts.

In D6073#182751, @inka wrote:

In D6073#182624, @tomek wrote:

Not sure if this is intentional, but x button seems to be shifted left. For me it would look better if the distance from the button to the right edge of the modal was the same as from the title to the left edge.

It looks a bit weird to me as well, but it's like that in the designs

Sounds reasonable. But now I'm wondering if introducing new action was a good idea. Maybe dispatching the old action (possibly with a new field e.g. type) might be easier? I don't think we should change it now, though.

Not sure if this is intentional, but x button seems to be shifted left. For me it would look better if the distance from the button to the right edge of the modal was the same as from the title to the left edge.

Does it still look correctly in dark mode?