In anticipation of have all unread message ids available to the
web app in page_params (via a separate effort), we are simplifying
the /topics endpoint to no longer return unread counts.
Instead we have a list of tiny dictionaries with these fields:
name - name of the topic
max_id - max message id for the topic (aka most recent)
The items in the list are order by most-recent-topic-first.
This mostly moves code, and it also removes some unnecessary
coupling to stream_data.js. The topic_data code purely
works in the stream_id space, so there's no need to set up
actual stream data for it.
We now call topic_data.add_message() and
topic_data.remove_message() when we get info about
incoming messages. The old way of passing in a boolean
made the calling code hard to read and added unncessary
conditional logic to the codepath.
We also have vague plans to change how we handle
removing topics, since increment/decrement logic is now
kind of fragile, so making the "remove" path more explicit
prepares us to something smarter in the future, like just
figure out when the last topic has been removed by calling
a filter function or something outside of topic_data.js.
Another thing to note here is that the code changed here
in echo.js is dead code, since we've disabled
message editing for locally edited messages. I considered
removing this code in a preparatory commit, but there's
other PR activity related to local echo that I don't want
to conflict with.
One nice aspect of removing process_message() is that
the new topic_data.js module does not refer to the legacy
field "subject" any more, nor do its node tests.
This commit introduces a per-stream topic_history class
inside of topic_data.js to better encapsulate how we store topic
history.
To the callers, nothing changes here. (Some of our non-black-box
node tests change their way of setting up data, though, since the
internal data structures are different.)
The new class has the following improvements:
* We use message_id instead of timestamp as our sorting key.
(We could have done this in a prep commit, but it wouldn't
have made the diff much cleaner here.)
* We use a dictionary instead of a sorted list to store the
data, so that writes are O(1) instead of O(NlogN). Reads
now do sorts, so they're O(NlogN) instead of O(N), but reads
are fairly infrequent. (The main goal here isn't actually
performance, but instead it just simplifies the
implementation.)
* We isolate `topic_history` from the format of the messages.
This prepares us for upcoming changes where updates to the
data structure may come from topic history queries as well
as messages.
* We split out the message-add path from the message-remove
path. This prepares us to eventually get rid of the "count"
mechanism that is kind of fragile and which has to be
bypassed for historical topics.
The var in question is indexed by stream_id, so stream_dict seems
like a good name for it. We want to distinguish per-stream data
structures from the stream-level entry points.
This new module tracks the recent topic names for any given
stream.
The code was pulled over almost verbatim from stream_data.js,
with minor renames to the function names.
We introduced a minor one-line function called stream_has_topics.
We now have all of our callers into recent_topics code just
receive a list of topic names from get_recent_topic_names().
This is more encapsulated than handing off tiny little
structures to the three callers, two of whom immediately
mapped the objects to names, and one of whom needlessly
used the now defunct name canon_subject field.
The consolidation here removes some "subject" references, and
now all lookup are by stream id, not stream name.
The diff here is a bit daunting, but it's mostly simplification
of tests and calling code. Two of the callers now need to look
up stream ids, but they are otherwise streamlined.
The main change here is to stream_data.js, and we replace the
`canon_subject` and `subject` fields with `name`.
We use multiple casings of "lunch" as a topic in our tests, so
that we verify that unread counts respect that topics are
not case sensitive.
We also eliminate an obsolete stub.
This is an issue where in jQuery v3 the result of outerHeight on a node
that doesn’t exist is now “undefined” rather than “null”, which means
it will no longer cast to a Number but rather NaN. For this, we create
the safeOuterHeight and safeOuterWidth functions to safely return a
result (or 0).
This is a better solution than manually going to each instance and
ORing it with 0 for type safety.
https://stackoverflow.com/questions/41454285/jquery-outerheight-returns-
undefined-instead-of-null
This removes the `no-new` rule which is relatively detrimental to
code cleanliness in our codebase because third-party libraries may
utilize data structures that don't fly well with our linting rules.
This also fixes abstractions that were created due to the limitations
and impositions of this lint rule.
Before the user profile bounding box width was not set so it
would overflow the 240px and there would be grey space next to
the avatar. Now the width is always maintained and long text
is cut into multiple lines.
This reverts commit a01eb190d6.
We haven't debugged why yet, but this was causing 2 major problems:
* Misalignment in the floating recipient bar area.
* Missing scrollbar in the right sidebar.
This changes a typo where a function was attempting to execute the
scope of the parent's "this" by using `function () {}.on()`, rather
than using the `Function.prototype.bind` built-in.
The ES6 backticks in /static/js/portico/landing-page.js were causing
the server to trip up. This was fixed by switching from JS string
interpolation to string concatenation (ES5).
Modified timerender.js absolute_time() to include the year
in the returned string when the supplied timestamp is in
an older year. This included adding an optional second
argument to specify the current date to facilitate unit
tests.
Fixes#5737.
This commit specifically addresses the issue when in preview mode,
while "enter sends" is enabled. Previously the messages were just
sent, now they must pass validation.
Fixes#5574.
Those buttons were contained in an anchor element. This isn't
valid HTML5 and caused the buttons to be focused on twice when
using tab-based navigation. Replacing the anchor with a form
element fixes this issue.
After editing this file for the previous commit, I couldn't unsee
"low-traffic the". So I fixed that, saw more issues, and then just
went through the page for everything that was similarly trivial to fix.
This route is called only in `js/compose.js`, to handle autosubscribe.
That code doesn't check this "exists" field, because there's no need
-- the same information is already carried in whether the result was
success or failure. So just eliminate it.
This makes the logic here a little simpler. It also eliminates
another usage of the `data` parameter to `json_error`. I have half a
mind to eliminate that parameter, in favor of making `JsonableError`
subclasses whenever there's structured data to include, in particular
to get the benefits of typing. There are a couple of places where
that change isn't locally a clear win, but this is not one of them.
Pweaver (Paul Weaver)
Steve Howell
Brock Whittaker
Harshit Bansal
Tim Abbott
Eeshan Garg
Vishnu Ks
digi0ps
James Rowan
Vaida Plankyte
David Coleman
hollywoodno
Rishi Gupta
Greg Price