Page MenuHomePhabricator

Call textMessageCreationSideEffectsFunc after sending DM text message
ClosedPublic

Authored by marcin on Fri, Sep 13, 6:12 AM.
Tags
None
Referenced Files
F2751567: D13334.diff
Wed, Sep 18, 2:50 PM
F2737954: D13334.id44172.diff
Tue, Sep 17, 7:29 PM
Unknown Object (File)
Tue, Sep 17, 1:19 AM
Unknown Object (File)
Sun, Sep 15, 7:18 PM
Unknown Object (File)
Sun, Sep 15, 6:35 PM
Unknown Object (File)
Sun, Sep 15, 1:19 AM
Unknown Object (File)
Sat, Sep 14, 11:41 PM
Unknown Object (File)
Sat, Sep 14, 8:01 PM
Subscribers

Details

Summary

This differential adds user to thick sidebar when another user mentions them in a message

Test Plan
  1. Create thick sidebar
  2. Send message mentioning a user
  3. Ensure that they are added to the sidebar

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.Mon, Sep 16, 1:17 AM

Setting @kamil to blocking on this as he recently refactored this logic – I want to make sure the changes still make sense to him. Sorry for any annoyance!

This revision now requires review to proceed.Mon, Sep 16, 9:59 AM

Before I start reviewing - can you rebase to the newest master?

You using code that was removed in D13329 so I guess this will change significantly.

kamil requested changes to this revision.Tue, Sep 17, 12:52 AM

Requesting changes to put back into your queue only

This revision now requires changes to proceed.Tue, Sep 17, 12:52 AM
native/input/input-state-container.react.js
576 ↗(On Diff #44264)

this is very ugly but recent changes on master (extracting sending message to hook) and the fact that we have this issue: https://linear.app/comm/issue/ENG-9103/update-processandsenddmoperation-to-support-multiple-dm-ops-at-once forces us to this change

It appears that the only thing this diff is doing is having textMessageCreationSideEffectsFunc called after the text message is created for thick threads, but before the text message is created for thin threads.

Two questions:

  1. Why do the side effects need to happen after the text message is created for thick threads?
  2. Should we just have the side effects run after the text message for thin threads as well?

It appears that the only thing this diff is doing is having textMessageCreationSideEffectsFunc called after the text message is created for thick threads, but before the text message is created for thin threads.

Two questions:

  1. Why do the side effects need to happen after the text message is created for thick threads?

This is explained in detail here

  1. Should we just have the side effects run after the text message for thin threads as well?

I haven't investigated this direction since current approach has been around for some time so I concluded that it is better not to change it we don't have to. However I think that we should keep the current approach for thin threads. If sending message succeeds but adding to thread fails the user receives a message form thread they don't belong to which is strange UX. We should update approach for thick threads as soon as it is possible ( after this is done).

This revision is now accepted and ready to land.Wed, Sep 18, 5:51 AM
This revision was landed with ongoing or failed builds.Wed, Sep 18, 7:13 AM
This revision was automatically updated to reflect the committed changes.