DirectThreadFragment:direct_thread, a conversation — or its composer.
Two entries, a sum on the input:
an existing thread, opened from the inbox list (kind: 'thread'): the
enter brings the thread to front, subscribes presence for the item's peers
and loads the conversation; the recording carries the presence and not the
thread GET (the inbox preview had the messages), but the library keeps no
local message store, so the screen loads it itself (the recorded deviation).
a picked recipient (kind: 'recipient'), from the inbox's "New message"
picker: the participant lookup (direct_v2/threads/get_by_participants/)
runs while the picker is still in front — the recorded order — and its
answer decides the screen's state. A conversation that already exists
(thread in the answer) is shown from that answer, and no presence is
subscribed — the 1:1 recording's answer names a hidden earlier thread with
no messages, and the app shows that empty conversation and subscribes
nothing. No conversation yet (the compose form, no thread) is the
composer: the screen comes to front, subscribes presence for the recipient
and shows the person. The never-contacted case is not recorded: the 1:1
run's account had a deleted conversation the server still named, so the
composer's own presence subscription, its recipient_users broadcast and
its conversation fetch are the group-creation shapes, and a run against an
account with no conversation at all closes them.
Actions take no list element as an argument: a reaction is the message's own
react, the nickname editor is the participant's own openNicknameEditor,
and each entry carries the thread context its action sends. A composer has no
thread id, so the details hub, Customize chat and the nickname editor are
refused there (DirectThreadNotCreatedError and the sub-screens' own
refusal); it shows no messages, so it has no reaction to offer.
The theme and nickname requests live on their own screens
(DirectCustomizeChat / DirectThreadThemePicker, DirectThreadNicknameChange).
DirectThreadFragment:direct_thread, a conversation — or its composer.Two entries, a sum on the input:
kind: 'thread'): the enter brings the thread to front, subscribes presence for the item's peers and loads the conversation; the recording carries the presence and not the thread GET (the inbox preview had the messages), but the library keeps no local message store, so the screen loads it itself (the recorded deviation).kind: 'recipient'), from the inbox's "New message" picker: the participant lookup (direct_v2/threads/get_by_participants/) runs while the picker is still in front — the recorded order — and its answer decides the screen's state. A conversation that already exists (threadin the answer) is shown from that answer, and no presence is subscribed — the 1:1 recording's answer names a hidden earlier thread with no messages, and the app shows that empty conversation and subscribes nothing. No conversation yet (the compose form, nothread) is the composer: the screen comes to front, subscribes presence for the recipient and shows the person. The never-contacted case is not recorded: the 1:1 run's account had a deleted conversation the server still named, so the composer's own presence subscription, itsrecipient_usersbroadcast and its conversation fetch are the group-creation shapes, and a run against an account with no conversation at all closes them.Actions take no list element as an argument: a reaction is the message's own
react, the nickname editor is the participant's ownopenNicknameEditor, and each entry carries the thread context its action sends. A composer has no thread id, so the details hub, Customize chat and the nickname editor are refused there (DirectThreadNotCreatedError and the sub-screens' own refusal); it shows no messages, so it has no reaction to offer.The theme and nickname requests live on their own screens (
DirectCustomizeChat/DirectThreadThemePicker,DirectThreadNicknameChange).