Linear task: ENG-3623
Details
Details
- Reviewers
inka tomek - Commits
- rCOMMc85cece9d9c3: [web] Fix chat composer when no active thread
Before this, the chat composer wouldn't open if there was no active thread. After this, it works fine, both when pressing the compose button and when loading it directly by navigating to http://localhost:3000/comm/chat/thread/new/
Note that the only way to get to a state with no active thread is load the web app when ALL threads are unread. (This is what happens when somebody creates a new account on web)
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Branch
- ashoat/webcomposer
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
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.).
| web/input/input-state-container.react.js | ||
|---|---|---|
| 605–609 | If we open thread composer in all unread state, are we able to upload an image or start typing which results in setting the draft? | |
| web/input/input-state-container.react.js | ||
|---|---|---|
| 605–609 | Saving a draft works, and creating a chat from a text message works. But creating a chat from an image appears broken. Thanks for calling this out | |
Comment Actions
The issues with threads started from images was more complicated than I realized.
- Part of the issue is addressed by this diff update. Previously useThreadInfoForPossiblyPendingThread was setting baseThreadInfo to null when activeChatThreadID wasn't set. This update makes it default to state.navInfo.pendingThread when there is no activeChatThreadID, which I think is the correct behavior.
- Part of the issue is that sendCallbacks were only getting triggered for text messages on web. I believe this was an oversight... it is triggered for media on native, and it needs to be triggered for media on web as well in order for the "search" to be closed when a thread is created with a media message. This will be addressed in the next diff.
- Part of the issue is that sendCallbacks would not be triggered from a retry. So if a user searched for a thread with an already-existing local pending message (that failed to send), the retry of the failed message would not clear the "search". This problem exists for native as well, and is addressed in yet another diff later in the stack.
- Finally, there is also ENG-3673: when creating a thread with an image, if you hit enter before the media is done uploading, the temporary image shown to you (the local blob URI) shows up as a [?]. I don't have a solution for this one yet, but it is not really related to this diff.