This allows several modules to no longer need
to import `narrow` (or, in our current pre-import
world, to not have to use that global).
The broken dependencies are reflected in the node
tests, which should now run slightly faster.
All of our data related to emojis is in emoji.js.
Now typeahead_helper no longer depends on emoji_picker.
Generally we want typeahead_helper to only depend
on data modules to avoid complicated circular
dependencies (or at least mitigate them).
This is part of work to break some of our
nastier circular dependencies in preparation
for our es6 migration.
This commit should facilitate loading leaf-like
modules such as people.js before all of the things
that reload.js depends on.
When you unsubscribe a stream by clicking on the
checkmark, we don't want it to disappear right
away, but we also don't need it to stay around
once you start searching for new streams.
Note from Tim: This commit removes some complex code that was just a
workaround for the fact that this widget used to automatically
re-filter immediately after clicking to unsubscribe a user.
Since we've since fixed that original issue, we don't need this.
We add a padded div to our container for the buddy
list to give scrolling the illusion that we've
rendered every list item, while still letting
the browser do the heavy lifting instead of trying
to fake it out too much.
This new div allows us to split out two concerns:
semantic list of items - remains in #user_presences
widget real estate - controlled by new #buddy_list_wrapper
We will use this for progressive rendering. We want to add
padding to the buddy list without messing with the integrity
of the actual HTML '<ul>' list. (One ugly alternative would
have been to add a dummy list item, which be a pitfall for
any code traversing the list.)
Basically, all the code relating to click handlers and similar
things was left alone. We only change js/css related to
scrolling, resizing, and overflow.
This version of progressive scrolling lazily
renders buddy list items, but it doesn't
provide the browser with any notion of upcoming
list items, so as you scroll down and the size
of the rendered list grows, the scrollbar shows
you being too close to the bottom.
This maintains 100% coverage on buddy_list.js.
In 47aaa73f96, we fixed one issue, which
is that server_events_dispatch.js was calling `update_starred` with
the wrong arguments, but created a new one (toggle_starred wasn't
updated) and missed another (which is that we weren't ever updating
message.starred, and thus if you toggle a message's star-state in one
browser, and then tried to toggle it back in a second, it would feel
like the click didn't work, because it was trying to toggle
e.g. off->on a second time).
This was supposed to be suppressed when a reload is in progress,
however, the logic was accidentally checking that
reload.is_in_progress was a defined function, not whether a reload was
actually in progress.
There was previously a race condition where reload.is_in_progress was
set after `activity.js` sent the presence request to the server, but
before we process the response; in that race condition, we still
shouldn't send blueslip errors to the server.
This renames Realm.restricted_to_domain field to
emails_restricted_to_domains, for greater clarity as to what it does
just from seeing the setting name, without having to look it up.
Fixes part of #10042.
We probably should have done this a while ago, even
though these functions are pretty tiny. The goal here
is to make it easier to have more consistent search
semantics.
Our first use case is subs.js. In this case we
are able to decouple a bit of generic string
matching from the subs-specific code.
We move some data code from subs.js to stream_data.js.
It's not clear we have been using the optimal sort for
dealing with locales, but this change preserves the
current behavior. The only subtle change here is that
we look up subs using a Dict now instead of a plain
JS object.
We now render the "skin" part of "Stream Settings" before
adding in the actual streams. The new function
populate_stream_settings_left_panel() takes care of adding
the streams. It uses a new template called
`subscriptions.handlebars`.
Splitting out this function will give us more flexibility
for various improvements.
First, we can decide to render the list after we open the
overlay, just to avoid the problem that users don't know why
the modal's opening. (And we could add a loader spinner as
needed.)
Second, we can improve our filter features so that we do
filtering in the data instead of moving DOM rows around,
which is expensive.
Third, we can eventually introduce progressive rendering.
Finally, having the function broken out will make profiling
more precise about where bottlenecks exist.
We were passing this in before, but having it as
a data member reinforces the idea that we'll want
this to be a first-class concept in the list, since
we depend on ordering for various things.
We now keep track of keys in buddy_list.js, so that
when we insert/remove items, we no longer need to
traverse all the DOM. Instead, we just find out
which position in the list we need to insert the
key in (where "key" is "user_id") and then find
the relevant DOM node directly and insert the new
HTML before that node. (And of course we still
account for the "append" case.)
There's a little more bookkeeping to make this
happen, but it should help reduce some code in
upcoming commits and pave the way toward
progressive rendering optimizations.
This commit should produce a minor speedup
for activity-related events that go through
buddy_list.insert_or_move(), since we are
not traversing the DOM to find insertion points
any more.
Typing "tim " did not did not produce any match when suggesting person
in composebox typeahead or user group typeahead as the space at the
end of the "tim " string passed by the browser was a
`no break-space (U+00A0)` instead of `space (U+0020)`.
Although there are unicode characters other than `no break-space` which
represent spaces, only U+00A0 is replaced as it was the only space
character encountered when testing this issue manually.
Fixes#10039.
To reduce code duplication when creating hotkey deprecation notices,
create the `get_hotkey_deprecation_notice` function. Also, create a
`ui` testing file with a test for the new function.
Fix#10004.
This replaces some old code with calls to topic_data.js.
Now our topic typeahead uses the same data as our
sidebar, stream suggestions, and the "n" key, so any
future improvements to that data will benefit all
features the same.
This is an important piece of #9857.
Now that `emoji_collection` and `emojis_by_name` are global
datasources in the webapp we need to rename things carefully
to reflect their actual meaning. The fact that emoji code is
used as a css class for unicode emoji is one thing but it is
not its sole use so renaming it seems a good idea.
This commit moves the `emoji_collection` datasource in the emoji
picker to emoji.js and renames it to `emojis_by_name`. It is a
mapping from emoji name to object where each object describes an
emoji. This is an effort in the direction of de-duplicating and
unifying the datasets being used by various our widgets(like
emoji picker and composebox typeahead) in the webapp. Migrating
all the widgets to a single datasource will help us in removing
the whole class of annoying bugs which causes some emojis to be
missing from some widgets.
This commit closes a long pending issue which involved moving the
`EMOTICON_CONVERSION` mapping to build_emoji infrastructure so
that there is only one source of truth. This was pending from the
time when this feature was implemented.
Steve Howell
Shubham Dhama
Tim Abbott
Joshua Pan
Roman Godov
Anders Kaseorg
Aditya Bansal
Cynthia Lin
Harshit Bansal
Shubham Padia
Marco Burstein