zulip/static/js/presence.js

257 lines
7.5 KiB
JavaScript
Raw Normal View History

"use strict";
const XDate = require("xdate");
2020-08-20 21:24:06 +02:00
const people = require("./people");
// This module just manages data. See activity.js for
// the UI of our buddy list.
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
// The following Maps have user_id as the key. Some of the
// user_ids may not yet be registered in people.js.
// See the long comment in `set_info` below for details.
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
// In future commits we'll use raw_info to facilitate
// handling server events and/or timeout events.
const raw_info = new Map();
exports.presence_info = new Map();
/* Mark users as offline after 140 seconds since their last checkin,
* Keep in sync with zerver/tornado/event_queue.py:receiver_is_idle
*/
const OFFLINE_THRESHOLD_SECS = 140;
const BIG_REALM_COUNT = 250;
exports.is_active = function (user_id) {
if (exports.presence_info.has(user_id)) {
const status = exports.presence_info.get(user_id).status;
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
if (status === "active") {
return true;
}
}
return false;
};
exports.get_status = function (user_id) {
if (people.is_my_user_id(user_id)) {
return "active";
}
if (exports.presence_info.has(user_id)) {
return exports.presence_info.get(user_id).status;
}
return "offline";
};
exports.get_user_ids = function () {
return Array.from(exports.presence_info.keys());
};
exports.status_from_raw = function (raw) {
/*
Example of `raw`:
{
active_timestamp: 1585745133
idle_timestamp: 1585745091
server_timestamp: 1585745140
}
*/
function age(timestamp) {
return raw.server_timestamp - (timestamp || 0);
}
const active_timestamp = raw.active_timestamp;
const idle_timestamp = raw.idle_timestamp;
let last_active;
if (active_timestamp !== undefined || idle_timestamp !== undefined) {
last_active = Math.max(active_timestamp || 0, idle_timestamp || 0);
}
/*
If the server sends us `active_timestamp`, this
means at least one client was active at this time
(and hasn't changed since).
As long as the timestamp is current enough, we will
show the user as active (even if there's a newer
timestamp for idle).
*/
if (age(active_timestamp) < OFFLINE_THRESHOLD_SECS) {
return {
status: "active",
last_active,
};
}
if (age(idle_timestamp) < OFFLINE_THRESHOLD_SECS) {
return {
status: "idle",
last_active,
};
}
return {
status: "offline",
last_active,
};
};
exports.update_info_from_event = function (user_id, info, server_timestamp) {
/*
Example of `info`:
{
website: {
client: 'website',
pushable: false,
status: 'active',
timestamp: 1585745225
}
}
Example of `raw`:
{
active_timestamp: 1585745133
idle_timestamp: 1585745091
server_timestamp: 1585745140
}
*/
const raw = raw_info.get(user_id) || {};
raw.server_timestamp = server_timestamp;
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
for (const rec of Object.values(info)) {
if (rec.status === "active" && rec.timestamp > (raw.active_timestamp || 0)) {
raw.active_timestamp = rec.timestamp;
}
if (rec.status === "idle" && rec.timestamp > (raw.idle_timestamp || 0)) {
raw.idle_timestamp = rec.timestamp;
}
}
raw_info.set(user_id, raw);
const status = exports.status_from_raw(raw);
exports.presence_info.set(user_id, status);
};
exports.set_info = function (presences, server_timestamp) {
/*
Example `presences` data:
{
6: Object { idle_timestamp: 1585746028 },
7: Object { active_timestamp: 1585745774 },
8: Object { active_timestamp: 1585745578 }
}
*/
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
raw_info.clear();
exports.presence_info.clear();
for (const [user_id_str, info] of Object.entries(presences)) {
const user_id = Number.parseInt(user_id_str, 10);
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
// Note: In contrast with all other state updates received
// receive from the server, presence data is updated via a
// polling process rather than the events system
// (server_events_dispatch.js).
//
// This means that if we're coming back from being offline and
// new users were created in the meantime, we may see user IDs
// not yet present in people.js if server_events doesn't have
// current data (or we've been offline, our event queue was
// GC'ed, and we're about to reload). Such user_ids being
// present could, in turn, create spammy downstream exceptions
// when rendering the buddy list. To address this, we check
// if the user ID is not yet present in people.js, and if it
// is, we skip storing that user (we'll see them again in the
// next presence request in 1 minute anyway).
//
// It's important to check both suspect_offline and
// reload_state.is_in_progress, because races where presence
// returns data on users not yet received via the server_events
// system are common in both situations.
const person = people.get_by_user_id(user_id, true);
if (person === undefined) {
if (!(server_events.suspect_offline || reload_state.is_in_progress())) {
// If we're online, and we get a user who we don't
// know about in the presence data, throw an error.
blueslip.error("Unknown user ID in presence data: " + user_id);
}
// Either way, we deal by skipping this user and
// continuing with processing everyone else.
continue;
}
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
const raw = {
server_timestamp,
active_timestamp: info.active_timestamp || undefined,
idle_timestamp: info.idle_timestamp || undefined,
};
presence: Prep for upcoming changes to server data. In the next commit we're going to change what the server sends for the following: - page_params - server responses to /json/users/me/presence We will **not** yet be changing the format of the data that we get in events when users update their presence. It's also just a bit in flux what our final formats will be for various presence payloads, and different optimizations may lead us to use different data structures in different payloads. So for now we decouple these two things: raw_info: this is intended to represent a snapshot of the latest data from the server, including some data like timestamps that are only used in downstream calculations and not user-facing exports.presence_info: this is calculated info for modules like buddy_data that just need to know active vs. idle and last_active_date Another change that happens here is we rename set_info_for_user to update_info_for_event, which just makes it clear that the function expects data in the "event" format (as opposed to the format for page_params or server responses). As of now keeping the intermediate raw_info data around feels slightly awkward, because we just immediately calculate presence_info for any kind of update. This may be sorta surprising if you just skim the code and see the various timeout constants. You would think we might be automatically expiring "active" statuses in the client due to the simple passage of time, but in fact the precise places we do this are all triggered by new data from the server and we re-calculate statuses immediately. (There are indirect ways that clients have timing logic, since they ask the server for new data at various intervals, but a smarter client could simply expire users on its own, or at least with a more efficient transfer of info between it and the server. One of the thing that complicates client-side logic is that server and client clocks may be out of sync. Also, it's not inherently super expensive to get updates from the server.)
2020-02-07 17:19:03 +01:00
raw_info.set(user_id, raw);
const status = exports.status_from_raw(raw);
exports.presence_info.set(user_id, status);
}
exports.update_info_for_small_realm();
};
exports.update_info_for_small_realm = function () {
if (people.get_active_human_count() >= BIG_REALM_COUNT) {
// For big realms, we don't want to bloat our buddy
// lists with lots of long-time-inactive users.
return;
}
// For small realms, we create presence info for users
// that the server didn't include in its presence update.
const persons = people.get_realm_users();
js: Automatically convert _.each to for…of. This commit was automatically generated by the following script, followed by lint --fix and a few small manual lint-related cleanups. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import { Context } from "ast-types/lib/path-visitor"; import K from "ast-types/gen/kinds"; import { NodePath } from "ast-types/lib/node-path"; import assert from "assert"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); const checkStatement = (node: n.Node): node is K.StatementKind => n.Statement.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; let inLoop = false; let replaceReturn = false; const visitLoop = (...args: string[]) => function(this: Context, path: NodePath) { for (const arg of args) { this.visit(path.get(arg)); } const old = { inLoop }; inLoop = true; this.visit(path.get("body")); inLoop = old.inLoop; return false; }; recast.visit(ast, { visitDoWhileStatement: visitLoop("test"), visitExpressionStatement(path) { const { expression, comments } = path.node; let valueOnly; if ( n.CallExpression.check(expression) && n.MemberExpression.check(expression.callee) && !expression.callee.computed && n.Identifier.check(expression.callee.object) && expression.callee.object.name === "_" && n.Identifier.check(expression.callee.property) && ["each", "forEach"].includes(expression.callee.property.name) && [2, 3].includes(expression.arguments.length) && checkExpression(expression.arguments[0]) && (n.FunctionExpression.check(expression.arguments[1]) || n.ArrowFunctionExpression.check(expression.arguments[1])) && [1, 2].includes(expression.arguments[1].params.length) && n.Identifier.check(expression.arguments[1].params[0]) && ((valueOnly = expression.arguments[1].params[1] === undefined) || n.Identifier.check(expression.arguments[1].params[1])) && (expression.arguments[2] === undefined || n.ThisExpression.check(expression.arguments[2])) ) { const old = { inLoop, replaceReturn }; inLoop = false; replaceReturn = true; this.visit( path .get("expression") .get("arguments") .get(1) .get("body") ); inLoop = old.inLoop; replaceReturn = old.replaceReturn; const [right, { body, params }] = expression.arguments; const loop = b.forOfStatement( b.variableDeclaration("let", [ b.variableDeclarator( valueOnly ? params[0] : b.arrayPattern([params[1], params[0]]) ), ]), valueOnly ? right : b.callExpression( b.memberExpression(right, b.identifier("entries")), [] ), checkStatement(body) ? body : b.expressionStatement(body) ); loop.comments = comments; path.replace(loop); changed = true; } this.traverse(path); }, visitForStatement: visitLoop("init", "test", "update"), visitForInStatement: visitLoop("left", "right"), visitForOfStatement: visitLoop("left", "right"), visitFunction(path) { this.visit(path.get("params")); const old = { replaceReturn }; replaceReturn = false; this.visit(path.get("body")); replaceReturn = old.replaceReturn; return false; }, visitReturnStatement(path) { if (replaceReturn) { assert(!inLoop); // could use labeled continue if this ever fires const { argument, comments } = path.node; if (argument === null) { const s = b.continueStatement(); s.comments = comments; path.replace(s); } else { const s = b.expressionStatement(argument); s.comments = comments; path.replace(s, b.continueStatement()); } return false; } this.traverse(path); }, visitWhileStatement: visitLoop("test"), }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-06 06:19:47 +01:00
for (const person of persons) {
const user_id = person.user_id;
let status = "offline";
if (exports.presence_info.has(user_id)) {
// this is normal, we have data for active
// users that we don't want to clobber.
js: Automatically convert _.each to for…of. This commit was automatically generated by the following script, followed by lint --fix and a few small manual lint-related cleanups. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import { Context } from "ast-types/lib/path-visitor"; import K from "ast-types/gen/kinds"; import { NodePath } from "ast-types/lib/node-path"; import assert from "assert"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); const checkStatement = (node: n.Node): node is K.StatementKind => n.Statement.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; let inLoop = false; let replaceReturn = false; const visitLoop = (...args: string[]) => function(this: Context, path: NodePath) { for (const arg of args) { this.visit(path.get(arg)); } const old = { inLoop }; inLoop = true; this.visit(path.get("body")); inLoop = old.inLoop; return false; }; recast.visit(ast, { visitDoWhileStatement: visitLoop("test"), visitExpressionStatement(path) { const { expression, comments } = path.node; let valueOnly; if ( n.CallExpression.check(expression) && n.MemberExpression.check(expression.callee) && !expression.callee.computed && n.Identifier.check(expression.callee.object) && expression.callee.object.name === "_" && n.Identifier.check(expression.callee.property) && ["each", "forEach"].includes(expression.callee.property.name) && [2, 3].includes(expression.arguments.length) && checkExpression(expression.arguments[0]) && (n.FunctionExpression.check(expression.arguments[1]) || n.ArrowFunctionExpression.check(expression.arguments[1])) && [1, 2].includes(expression.arguments[1].params.length) && n.Identifier.check(expression.arguments[1].params[0]) && ((valueOnly = expression.arguments[1].params[1] === undefined) || n.Identifier.check(expression.arguments[1].params[1])) && (expression.arguments[2] === undefined || n.ThisExpression.check(expression.arguments[2])) ) { const old = { inLoop, replaceReturn }; inLoop = false; replaceReturn = true; this.visit( path .get("expression") .get("arguments") .get(1) .get("body") ); inLoop = old.inLoop; replaceReturn = old.replaceReturn; const [right, { body, params }] = expression.arguments; const loop = b.forOfStatement( b.variableDeclaration("let", [ b.variableDeclarator( valueOnly ? params[0] : b.arrayPattern([params[1], params[0]]) ), ]), valueOnly ? right : b.callExpression( b.memberExpression(right, b.identifier("entries")), [] ), checkStatement(body) ? body : b.expressionStatement(body) ); loop.comments = comments; path.replace(loop); changed = true; } this.traverse(path); }, visitForStatement: visitLoop("init", "test", "update"), visitForInStatement: visitLoop("left", "right"), visitForOfStatement: visitLoop("left", "right"), visitFunction(path) { this.visit(path.get("params")); const old = { replaceReturn }; replaceReturn = false; this.visit(path.get("body")); replaceReturn = old.replaceReturn; return false; }, visitReturnStatement(path) { if (replaceReturn) { assert(!inLoop); // could use labeled continue if this ever fires const { argument, comments } = path.node; if (argument === null) { const s = b.continueStatement(); s.comments = comments; path.replace(s); } else { const s = b.expressionStatement(argument); s.comments = comments; path.replace(s, b.continueStatement()); } return false; } this.traverse(path); }, visitWhileStatement: visitLoop("test"), }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-06 06:19:47 +01:00
continue;
}
if (person.is_bot) {
// we don't show presence for bots
js: Automatically convert _.each to for…of. This commit was automatically generated by the following script, followed by lint --fix and a few small manual lint-related cleanups. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import { Context } from "ast-types/lib/path-visitor"; import K from "ast-types/gen/kinds"; import { NodePath } from "ast-types/lib/node-path"; import assert from "assert"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); const checkStatement = (node: n.Node): node is K.StatementKind => n.Statement.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; let inLoop = false; let replaceReturn = false; const visitLoop = (...args: string[]) => function(this: Context, path: NodePath) { for (const arg of args) { this.visit(path.get(arg)); } const old = { inLoop }; inLoop = true; this.visit(path.get("body")); inLoop = old.inLoop; return false; }; recast.visit(ast, { visitDoWhileStatement: visitLoop("test"), visitExpressionStatement(path) { const { expression, comments } = path.node; let valueOnly; if ( n.CallExpression.check(expression) && n.MemberExpression.check(expression.callee) && !expression.callee.computed && n.Identifier.check(expression.callee.object) && expression.callee.object.name === "_" && n.Identifier.check(expression.callee.property) && ["each", "forEach"].includes(expression.callee.property.name) && [2, 3].includes(expression.arguments.length) && checkExpression(expression.arguments[0]) && (n.FunctionExpression.check(expression.arguments[1]) || n.ArrowFunctionExpression.check(expression.arguments[1])) && [1, 2].includes(expression.arguments[1].params.length) && n.Identifier.check(expression.arguments[1].params[0]) && ((valueOnly = expression.arguments[1].params[1] === undefined) || n.Identifier.check(expression.arguments[1].params[1])) && (expression.arguments[2] === undefined || n.ThisExpression.check(expression.arguments[2])) ) { const old = { inLoop, replaceReturn }; inLoop = false; replaceReturn = true; this.visit( path .get("expression") .get("arguments") .get(1) .get("body") ); inLoop = old.inLoop; replaceReturn = old.replaceReturn; const [right, { body, params }] = expression.arguments; const loop = b.forOfStatement( b.variableDeclaration("let", [ b.variableDeclarator( valueOnly ? params[0] : b.arrayPattern([params[1], params[0]]) ), ]), valueOnly ? right : b.callExpression( b.memberExpression(right, b.identifier("entries")), [] ), checkStatement(body) ? body : b.expressionStatement(body) ); loop.comments = comments; path.replace(loop); changed = true; } this.traverse(path); }, visitForStatement: visitLoop("init", "test", "update"), visitForInStatement: visitLoop("left", "right"), visitForOfStatement: visitLoop("left", "right"), visitFunction(path) { this.visit(path.get("params")); const old = { replaceReturn }; replaceReturn = false; this.visit(path.get("body")); replaceReturn = old.replaceReturn; return false; }, visitReturnStatement(path) { if (replaceReturn) { assert(!inLoop); // could use labeled continue if this ever fires const { argument, comments } = path.node; if (argument === null) { const s = b.continueStatement(); s.comments = comments; path.replace(s); } else { const s = b.expressionStatement(argument); s.comments = comments; path.replace(s, b.continueStatement()); } return false; } this.traverse(path); }, visitWhileStatement: visitLoop("test"), }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-06 06:19:47 +01:00
continue;
}
if (people.is_my_user_id(user_id)) {
status = "active";
}
exports.presence_info.set(user_id, {
status,
last_active: undefined,
});
js: Automatically convert _.each to for…of. This commit was automatically generated by the following script, followed by lint --fix and a few small manual lint-related cleanups. import * as babelParser from "recast/parsers/babel"; import * as recast from "recast"; import * as tsParser from "recast/parsers/typescript"; import { builders as b, namedTypes as n } from "ast-types"; import { Context } from "ast-types/lib/path-visitor"; import K from "ast-types/gen/kinds"; import { NodePath } from "ast-types/lib/node-path"; import assert from "assert"; import fs from "fs"; import path from "path"; import process from "process"; const checkExpression = (node: n.Node): node is K.ExpressionKind => n.Expression.check(node); const checkStatement = (node: n.Node): node is K.StatementKind => n.Statement.check(node); for (const file of process.argv.slice(2)) { console.log("Parsing", file); const ast = recast.parse(fs.readFileSync(file, { encoding: "utf8" }), { parser: path.extname(file) === ".ts" ? tsParser : babelParser, }); let changed = false; let inLoop = false; let replaceReturn = false; const visitLoop = (...args: string[]) => function(this: Context, path: NodePath) { for (const arg of args) { this.visit(path.get(arg)); } const old = { inLoop }; inLoop = true; this.visit(path.get("body")); inLoop = old.inLoop; return false; }; recast.visit(ast, { visitDoWhileStatement: visitLoop("test"), visitExpressionStatement(path) { const { expression, comments } = path.node; let valueOnly; if ( n.CallExpression.check(expression) && n.MemberExpression.check(expression.callee) && !expression.callee.computed && n.Identifier.check(expression.callee.object) && expression.callee.object.name === "_" && n.Identifier.check(expression.callee.property) && ["each", "forEach"].includes(expression.callee.property.name) && [2, 3].includes(expression.arguments.length) && checkExpression(expression.arguments[0]) && (n.FunctionExpression.check(expression.arguments[1]) || n.ArrowFunctionExpression.check(expression.arguments[1])) && [1, 2].includes(expression.arguments[1].params.length) && n.Identifier.check(expression.arguments[1].params[0]) && ((valueOnly = expression.arguments[1].params[1] === undefined) || n.Identifier.check(expression.arguments[1].params[1])) && (expression.arguments[2] === undefined || n.ThisExpression.check(expression.arguments[2])) ) { const old = { inLoop, replaceReturn }; inLoop = false; replaceReturn = true; this.visit( path .get("expression") .get("arguments") .get(1) .get("body") ); inLoop = old.inLoop; replaceReturn = old.replaceReturn; const [right, { body, params }] = expression.arguments; const loop = b.forOfStatement( b.variableDeclaration("let", [ b.variableDeclarator( valueOnly ? params[0] : b.arrayPattern([params[1], params[0]]) ), ]), valueOnly ? right : b.callExpression( b.memberExpression(right, b.identifier("entries")), [] ), checkStatement(body) ? body : b.expressionStatement(body) ); loop.comments = comments; path.replace(loop); changed = true; } this.traverse(path); }, visitForStatement: visitLoop("init", "test", "update"), visitForInStatement: visitLoop("left", "right"), visitForOfStatement: visitLoop("left", "right"), visitFunction(path) { this.visit(path.get("params")); const old = { replaceReturn }; replaceReturn = false; this.visit(path.get("body")); replaceReturn = old.replaceReturn; return false; }, visitReturnStatement(path) { if (replaceReturn) { assert(!inLoop); // could use labeled continue if this ever fires const { argument, comments } = path.node; if (argument === null) { const s = b.continueStatement(); s.comments = comments; path.replace(s); } else { const s = b.expressionStatement(argument); s.comments = comments; path.replace(s, b.continueStatement()); } return false; } this.traverse(path); }, visitWhileStatement: visitLoop("test"), }); if (changed) { console.log("Writing", file); fs.writeFileSync(file, recast.print(ast).code, { encoding: "utf8" }); } } Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
2020-02-06 06:19:47 +01:00
}
};
exports.last_active_date = function (user_id) {
const info = exports.presence_info.get(user_id);
if (!info || !info.last_active) {
return undefined;
}
const date = new XDate(info.last_active * 1000);
return date;
};
exports.initialize = function (params) {
exports.set_info(params.presences, params.initial_servertime);
};
window.presence = exports;