mirror of
https://github.com/zulip/zulip.git
synced 2025-11-04 05:53:43 +00:00
855ac26c48
We extract compose_fade_users and compose_fade_helper.
This is a pretty verbatim extraction of code, apart from adding a few
exports and changing the callers.
This change makes the buddy_data module no longer sit "above" these
files in the dependency graph (at least not via compose_fade):
* jquery
* lodash (not a big deal)
* compose_state
* floating_recipient_bar
* message_viewport
* rows
The new moules have dependencies that buddy_data already
had directly for other reasons:
* people
* util
And then buddy_data still depends on stream_data indirectly through
the compose-fade logic for stream_data. Even without compose-fade, it
would depend indirectly on stream_data via hash_util.
Note that we could have lifted the calls to compose_fade out of
buddy_data to move some dependencies around, but it's useful to have
buddy_data fully encapsulate what goes into the buddy list without
spreading responsibilities to things like activity.js and
buddy_list.js. We can now unit-test the logic at the level of
buddy_data, which is a lot easier than trying to do it via modules
that delegate drawing or do drawing (such as activity.js and
buddy_list.js).
Note that we still don't have 100% line coverage on the
compose_fade.js module, but all the code that we extracted now is
covered, mostly via buddy_data tests.
60 lines
1.9 KiB
JavaScript
60 lines
1.9 KiB
JavaScript
import * as stream_data from "./stream_data";
|
|
import * as util from "./util";
|
|
|
|
let focused_recipient;
|
|
|
|
export function should_fade_message(message) {
|
|
return !util.same_recipient(focused_recipient, message);
|
|
}
|
|
|
|
export function clear_focused_recipient() {
|
|
focused_recipient = undefined;
|
|
}
|
|
|
|
export function set_focused_recipient(recipient) {
|
|
focused_recipient = recipient;
|
|
}
|
|
|
|
export function would_receive_message(user_id) {
|
|
if (focused_recipient.type === "stream") {
|
|
const sub = stream_data.get_sub_by_id(focused_recipient.stream_id);
|
|
if (!sub) {
|
|
// If the stream isn't valid, there is no risk of a mix
|
|
// yet, so we sort of "lie" and say they would receive a
|
|
// message.
|
|
return true;
|
|
}
|
|
|
|
return stream_data.is_user_subscribed(focused_recipient.stream_id, user_id);
|
|
}
|
|
|
|
// PM, so check if the given email is in the recipients list.
|
|
return util.is_pm_recipient(user_id, focused_recipient);
|
|
}
|
|
|
|
export function want_normal_display() {
|
|
// If we're not composing show a normal display.
|
|
if (focused_recipient === undefined) {
|
|
return true;
|
|
}
|
|
|
|
// If the user really hasn't specified anything let, then we want a normal display
|
|
if (focused_recipient.type === "stream") {
|
|
// If a stream doesn't exist, there is no real chance of a mix, so fading
|
|
// is just noise to the user.
|
|
if (!stream_data.get_sub_by_id(focused_recipient.stream_id)) {
|
|
return true;
|
|
}
|
|
|
|
// This is kind of debatable. If the topic is empty, it could be that
|
|
// the user simply hasn't started typing it yet, but disabling fading here
|
|
// means the feature doesn't help realms where topics aren't mandatory
|
|
// (which is most realms as of this writing).
|
|
if (focused_recipient.topic === "") {
|
|
return true;
|
|
}
|
|
}
|
|
|
|
return focused_recipient.type === "private" && focused_recipient.reply_to === "";
|
|
}
|