For now it is ok, but in the future we probably should introduce a prop that is e.g. a flag and tells InlineEngagement what should be done in reaction to the click. There might be some cases, in the future, where closing the modal is not desirable.

By the way - on the local environment fetching messages is fast. On the prod it might be a lot slower - should we display a spinner or something? How would the UI look if messages are being fetched?

This diff causes eslint to fail. Please fix it.

Looks ok, but please make sure that the creator is not only displayed, but also can be used (type a message, include an image, etc.).

I'm not too familiar with this logic, but seems reasonable.

Could you also share a screenshot from Android?

Extract icon to a file

In D7350#219550, @kamil wrote:

Can you share a screenshot of how it looks?

Rebase and update background image

Rebase and update background image

Rebase

Early return

Update font size

Update font weight and size

Some questions about types, and please update the declaration of payload.

As simple change as this should be put into the original diff - I moved it there. The special font should still be used for the title, but that will be done in a separate diff.

Specify doctype

Use new design

Move function to website responders - we're going to use some functions from that file.

Seems like empty toggle-pin-modal.css file was added by accident.

Limit set of allowed chars in the secret.
Make code more readable by using encode function.

Throttling is a great improvement compared to just calling this function but it still might break when db save takes more than 300ms. We should probably handle that case differently.

This looks ok, but we should also update the databases in our local environments. Do we have a plan for this?

It seems like most of the comments request only simple changes, but there are a lot of them

Requesting changes because we should refactor the code

Move import

Move import

In D7175#214618, @rohan wrote:

In D7175#213494, @tomek wrote:

So basically, this code handles only the pin icon next to a message on message list. And it's not intended to provide data for pinned list, right?

Yeah, exactly!

The only concern is that we probably don't pin messages in transaction. That means that we can successfully update pin status in the db, but fail to create TOGGLE_PIN message. A lot more reliable approach would be to add a field to a message saying that it is pinned.

You're right, I don't believe we pin the messages in a transaction. So the DB for the message gets updated on pin/unpin (pinned and pin_time), and we separately create a message of type === TOGGLE_PIN. So are you suggesting instead of determining isPinned by the messages, we instead determine isPinned by it's state in the DB (pinned = 1 or pinned = 0)?

It wasn't initially obvious to me that this is the right approach. But after some time it seems to make sense.