compose: Support editing an already-sent message #126
Comments
gnprice
added
the
a-msglist
|
When we implement this, we should aim to offer editing on all message lists, including "All messages" (zulip/zulip-mobile#5619). If we successfully keep at least the code cleanly separated from that for composing a new message, as described above, then that should be straightforward. (Potentially we'll decide that we want the UX for editing to remain similar to that for composing a message after all. In that case the code will probably have significant pieces in common. But the key will just be to have the differences between edit and compose cleanly factored out, rather than the edit logic being jammed in awkwardly as it is in zulip-mobile.) |
|
This now has a design — thanks @terpimost! I've edited the issue description to show the design. Chat thread on a couple of specific points in the design:
Those points have been resolved now; Vlad edited the Figma design and I edited the description above, and together those have the current design that's ready for implementation. |
|
We've had a few requests for this in beta feedback: https://chat.zulip.org/#narrow/channel/48-mobile/topic/Flutter.20beta.3A.20cannot.20edit.20messages/near/2011951 |
|
Hello I want to work on this issue. Please assign this to me. WhatsApp.Video.2025-01-30.at.8.12.20.PM.mp4 |
|
@lakshya1goel Sounds good, thanks. As I mentioned just now at #1314 (comment), let's pause work on post-launch features like this one until after the launch is ready; but we can plan for you to pick up the work from there, if you'd like, when that time comes. (And as a result we'll leave it "unassigned" in GitHub for now, just because I like to reserve the GitHub "assignment" feature on issues to track what work is actively happening rather than what work is planned for the future.) |
|
I misread when writing my previous comment above: this is a launch issue, not post-launch. It's a feature we'd like to have in time for the app's launch, because the legacy app has it and we've heard from beta users that they miss it. It's also a complex feature whose logic will intertwine deeply with the existing code for the compose box, and is likely to involve some refactors to that code. It'd be easy for an implementation of this, if not careful, to end up not only being hard to understand (and therefore prone to bugs, and expensive to make changes to) but also making the compose box in general hard to understand even when not trying to think about the editing case. That's the situation of the corresponding logic in zulip-mobile, which I've never been satisfied by. For those reasons this is a feature that we'll want someone from the core team to be driving in order to end up with a successful implementation, and I've asked @chrisbobbe to take it on. @lakshya1goel thanks for trying this out; I'd encourage first revising your reviewed PRs, and then taking a look at our other launch issues. On the board I see at least one "help wanted" launch issue still unclaimed. |
With this API, we can use showSuggestedActionDialog in an "early return" style -- await the user's choice, and early return if it was "Cancel". That's particularly helpful when the confirmation dialog belongs in an `if` block. We'll use this for the upcoming "edit message" feature (zulip#126), where we plan to offer a confirmation dialog before entering an edit-message session, but only if the compose box has text for a new message in it (which would be discarded if the user wants to go ahead).
With this API, we can use showSuggestedActionDialog in an "early return" style -- await the user's choice, and early return if they chose to dismiss the dialog. That's particularly helpful when the confirmation dialog is opened in an `if` block. We'll use this for the upcoming "edit message" feature (zulip#126), where we plan to offer a confirmation dialog before entering an edit-message session, but only if the compose box has text for a new message in it (which would be discarded if the user wants to go ahead).
With this API, we can use showSuggestedActionDialog in an "early return" style -- await the user's choice, and early return if they chose to dismiss the dialog. That's particularly helpful when the confirmation dialog is opened in an `if` block. We'll use this for the upcoming "edit message" feature (zulip#126), where we plan to offer a confirmation dialog before entering an edit-message session, but only if the compose box has text for a new message in it (which would be discarded if the user wants to go ahead).
This needs tests for: - compose box - message list Fixes: zulip#126
Design from @terpimost:
Details are in Figma:
https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=4010-6347&m=dev
Updates from the details in Figma:
Original description:
We should probably offer this as an in-place text field within the message list. As Greg points out about this feature in
zulip-mobile(link):The text was updated successfully, but these errors were encountered: