The tooltips for the left panel of stream settings
have been broken since November 2018 due to my
commit 8f915da2ca.
The code prior to 2018 was restoring tooltips
right inside the loop where we were detaching
the row from the DOM to put it back into the
DOM at another place. And then I tried to
just add them in bulk, forgetting that I was
in the middle of all the DOM manipulation (and
hence my selector for the loop was a noop).
Also, I don't think we've ever had them for live
events that add streams. (I fixed that too.)
It's not clear to me that this code is actually
necessary, as we get hover help without
calling $(...).tooltip(...) properly.
This is probably why we didn't notice any
breakage when we merged my 2018 commit.
We generally want to avoid clicking on DOM elements
that may not actually be visible due to the prior
operation. Instead, we can just find the visible
element after each step.
I also introduce a couple helper functions to
de-clutter the click/unclick/click steps, and I do
a couple extra clicks for good measure.
You can verify that the test will fail if you
add an early return to update_check_button_for_sub.
We just want to reset the scrollbar here, which
we still do via ui.reset_scrollbar.
You don't want to preserve scroll position if
you are filtering or re-sorting.
We have long had this annoying two-pass way of building the
DOM that I am trying to eliminate.
The function names that I introduce here describe the current
situation more accurately.
In passing I make it so that we only throttle redraws when
users are actually typing. Using a throttled redraw when
you click on the sort icons is at best unnecessary, and it
may actually aggravate double clicks.
This splits the one big `run_test` block into
add/edit/delete parts, for better clarity.
This also removes the `with_field` calls and
uses the override style instead, which is
preferred because it makes sure the stubbed
function is actually called.
This commit replaces `with_field` calls to
use the override style instead.
`override` is preferred since it makes sure
the stubbed function is actually called,
while `with_field` doesn't, which makes it
hard to spot dead code.
This commit replaces all `with_stub` calls and
explicitly calls `make_stub` instead.
The `with_stub` helper does not add much clarity
hence we now use scoped stub objects instead.
This de-indents some blocks where scoping isn't
required, for example when there is a single
stub object inside a `run_test` function.
With this change, we also need to explicitly
assert `num_calls`.
We can relax this restriction in the future, but
basically every time it came up for me, the test
code was just disorganized, or it had an easy
workaround.
These are still kind of a mess.
The old code combined the worst of both worlds:
- we had one monolithic test
- we called the events multiple times,
verifying a different stub each time
Now I make the tests more granular.
We could actually re-combine the tests, but
in a nicer way, so that we just set
up multiple stubs and verify that all stubs
get correctly invoked.
There is also some code cleanup here--in dispatch_subs,
we don't stub stream_data, so it's easier to write
deeper tests that actually validate the data changes.
This prevents a bug where we interpret "2something"
as a modern slug instead of a legacy stream name.
The bug was probably somewhat unlikely to happen in
practice, since it only manifests if 2 is an actual
stream_id.
We still need to write to these globals with set_global because the
code being tested reads from them, but the tests themselves should
never need to read from them.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit makes it so that MessageListData
methods always attempt to filter muted messages.
We later, in a new function
(`messages_filtered_for_topic_mutes`)
check if `excludes_muted_topics` is true or not,
and skip the filtering work if it isn't.
This new function consistently returns a new list.
This refactor will later allow us to write clean
and concise code as part of mute users.
This commit also refactors the muting tests
for MessageListData, which were earlier
spread across two `run_test` functions.
These tests should remain organized,
since similar tests will be added as part of
user mutes in future commits.
Previously, the `muting_enabled` property of
MessageListData class was used to indicate whether
some messages in the message list need to be
filtered due to topic muting, depending on the
narrow. For example, we exclude messages belonging
to muted topics from stream narrows, but not from
search narrows.
The name `muting_enabled` is a bit confusing, and hence is
changed to `excludes_muted_topics`.
It is also important that the name be specific, since
a similar new property will be added for user mutes
in future commits.
I have a local branch with a hacked up version of
zjquery that lets you basically detect when zjquery
stubs are never actually invoked by real code.
There are some nuances to that kind of audit, so
I haven't pushed the auditing code, but these
are low hanging fruit.
I now just use inline the code to create stubs
for the line items in the markdown_content
container, and I don't add methods to the
zjquery stubs.
And then I use the new "children" feature in
zjquery's `$.create(sel, opts)` to set up
$(".markdown_content"), which means I don't
have to stub `each` any more.
It's actually pretty rare in our codebase to
call methods like `$(...).map` or `$(...).each`,
but we now support them better in zjquery.
You can pass a list of child elements now to
`$.create(...)`.
Fixes the sorting button labels in stream settings, which were
regressed by commit f8fbae4d8e (because
the HTML was not marked as being HTML).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is a minor refactor in the muting test in
`message_list`.
The `unmuted_messages` function filters out messages only
considering topic mutes, and not stream mutes.
The test previously made it look like we were testing
stream muting, by stubbing the `is_topic_muted` on the
basis of `stream_id`.
This also replaces the stub and uses real data instead.
This is a prep commit, which renames some variables
and functions involved in topic muting to include
the word "topic" in them.
This is done to have clarity when similar code
will be added as a part of the mute-user in
future commits.
Replaced methods/functions of moment.js with date-fns library.
The motive was to replace it with a smaller frontend timezone library.
Date-fns ~ 11.51 kb
moment.js ~ 217.87 kb
Some of the format strings change because date-fns encodes them
differently from how moment did.
Fixes#16373.
It's not clear to me why this code was necessary,
and I assume it was either originally written
with a bit of misunderstanding of how zjquery
works or it became unnecessary with some refactoring
of the "real" code.
We move some of the data setup to the top of the file.
We also remove some get_sub() calls that aren't really
necessary now that peer_data and stream_data are more
independent.
The maybe_clear_subscribers() function was an artifact of
when we used to attach subscribers to the "sub" records in
stream_data.js. I think it was basically a refactoring
shim, and due to some other recent cleanup, it was only
used in test code.
We also change how we validate stream ids.
Going forward, peer_data just looks up stream_ids with the
normal stream_data API when it's trying to warn about
rogue stream_ids coming in. As I alluded to in an earlier
commit, some of the warning code here might be overly
defensive, but at least it's pretty self-contained.
Now when we want to measure how long a block
of code takes to execute, we just wrap it with
`blueslip.measure_time`, instead of the awkward
idiom from my original commit of getting a callback
function.
My rationale for the original scheme was that I
wanted to minimize diffs and avoid changing
`const` to `let` in a few cases, but I believe
now that the function wrapper is nicer.
In a few cases I just removed the blueslip timing
code, since I was able to confirm on czo that
the times were pretty minimal.
We now use the same code in all places to
get the bucket of user_ids that correspond
to a stream, and we consistently treat
a stream as having zero subscribers, not
an undefined number of subscribers, in
the hypothetical case of us asking about
a stream that we're not tracking.
The behavior for untracked streams has
always been problematic, since if a
stream is untracked, all bets are off.
So now if we don't "track" the stream,
the subscriber count is zero. None of
our callers distinguish between undefined
and zero.
And we just consider the stream to be subscribed
by a user when add_subscriber is called,
even if we haven't been told by stream_data
to track the stream. (We also stop
returning true/false from add_subscriber,
since only test code was looking at it.)
We protect against the most likely source
of internal-to-the-frontend bugs by adding
the assert_number() call.
We generally have to assume that the server
is sending us sensible data at page load
time, or all bets are off.
And we have good protections in place
for unknown ids in our dispatch code
for peer_add/peer_remove events.
We also streamline some of the error handling code
by doing everything up front. This will prevent
scenarios where a single bad stream_id/user_id causes a
bunch of the same warnings in an inner loop.
Steve Howell
Abhijeet Prasad Bodas
Anders Kaseorg
aryanshridhar
Ganesh Pawar