In D7066#214942, @inka wrote:

Thank you for adding the link to the task. The DES task you linked is for Desktop though, and this is Native. Was it decided anywhere that we should use Desktop designs for Native?

In D7128#214943, @inka wrote:

What about the test plan?

Removed logic from JSX

Responded to review

In D7066#214557, @inka wrote:

What designs are you using? The designs I found (here) show the label next to the message.
I also see no comments regarding this, in what I guess is the task this diff is addressing (here)

Added invariant & removed redundant error catching.

Removed redundant error payload & moved redux types to the end of the file

Added keys to the components list to prevent key error

Changed the way of displaying new content of edited message in the sidebar

Removed accidentally added empty line

Removed 'Edited' label from the pending thread to match D7141 changes

Removed redundant code

In D7065#212932, @ashoat wrote:

In D7065#212101, @ashoat wrote:

Will this affect the height of the item? Have you made the necessary changes to the height determination code (textMessageItemHeight)?

Requesting changes for my question above

Added messageHeight of edited messages

Rebase to master

Set id to readonly

Rebase

Rebase

Rebase

Rebase

Address comments

Change type to inexact

Address review comments

Address comments

In D6965#212104, @ashoat wrote:

We can consider preventing users from sending empty edit messages.

We should do this. We don't allow empty messages for messageTypes.TEXT. Can you create a follow-up Linear task for this before landing?

Addressed some of the comments

Revert the changes

Simplified condition

Added message type for error message

id is no longer nullable

In D6961#211322, @ashoat wrote:

Can you clarify in what scenarios the id can be null? Usually we only see that for types that also have localID

Simplified text variable

Added unique keys to the rendered components

Addressed @ginsu feedback from the web version of diff

The same comments as in: https://phab.comm.dev/D7017?id=23714#inline-46406

Addressed @ginsu comments

In D7017#210367, @ginsu wrote:

Also, I personally feel like the label for edited messages should be below the reactions/threads and not to the left/right of it. Could you link or send a screenshot of what the figma has?

Removed localID from the type

@inka fixed this in another diff.

In D7017#209805, @ashoat wrote:

Can you share an updated screenshot?

Aligned 'Delivery failed' notice to the message label. Only for the right side, because we can't get delivery failed on the left side.

In D6963#209536, @tomek wrote:

The proper way of testing older clients involves running an older client in prod mode (so that it won't get hot reloaded when we update the code version), then checking out the newest code, and running the server with this code. In this case we can consider a simplified approach: the thing which interests us the most is if the server sends an original message or the shimmed version. To test that we can run a client and set code version in the condition on the keyserver. If the client's version is higher than server's, we should receive an original message. Otherwise, it should be the shimmed one.

Changed minCodeVersion for messageShimming

I don't know how to test message shimming yet, so for now it isn't tested.

Added shimming message info, changed content to JSON format.

In D7017#209165, @michal wrote:

Can you check what it looks like with the "Delivery failed. RETRY?" text which appears when sending a message, and attach a screenshot? Not sure if this case was considered in the designs.

In D6963#208218, @ginsu wrote:

I think we should consider if we also need shimUnsupportedMessageInfo and unshimMessageInfo. These functions will help us support older native clients that haven't been updated yet.

Responded to comments

Removed 'hasBeenEdited' variable from 'RobotextChatMessageInfoItem'

Add 'hasBeenEdited' to code for native to be able to access the variable

In D6966#207758, @ashoat wrote:

Can we avoid putting this in TextMessageInfo? I don't think it belongs there... and you're doing something pretty inconsistent with how we approached reactions.

Why didn't you put this in ChatMessageInfoItem? (In the future, when you are doing something different like this, please expect that your reviewers will call you out on it, and explain it ahead of time.)

Moved 'hasBeenEdited' property to 'ChatMessageInfoItem' type

Responded to comments, made hasBeenEdited property read-only

Responded to comments, made read-only 'text' property

In D6961#207350, @ashoat wrote:

Can you also updates lib/types/messages.js? EDIT ah I see these are in the next diff

In general I personally find it better to introduce types along with code that actually uses them, but many people on the team do what you did here and introduce them in a separate diff. It just makes it much harder to test... eg. your Test Plan doesn't actually test any of the types at all, which means it's quite a poor test plan.