Processing all custom emojis is neither wise nor necessary as both `Like` and `EmojiReact` only expect a single custom emoji
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
These occur when an account tries to react with disabled custom emojis.
In both `EmojiReact` and `Like? activities, the activity is discarded.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
The Unicode sequence for this emoji starts with an
ASCII # character, which the browser's URI parser
truncates before sending the request to the
backend.
Akkoma and possibly others expect the `tag` field
in an EmojiReact activity to be an array, not just
a single object, so it's being wrapped into one
now. I'm not entirely sure whether this is the
idiomatic way of doing it tbh, but it works fine.
Using an emoji map was completely unnecessary in
the first place, because the reaction list from
the API response includes URLs for every custom
emoji anyway. The reaction list now also contains
a boolean field indicating whether it is an
external custom emoji, which is required because
people should only be able to react with Unicode
emojis and local custom ones, not with custom
emojis from other servers.
Emoji reactions containing custom emojis from
remote instances were assumed to already have
been downloaded and stored in the database.
This might obviously not be the case.
The margins of the elements above and below the
main reaction list element overlapped before
reactions were added. Adding display: none to
empty reaction bars restores this exact look.
This also adds the comment in action_bar.js to
status_action_bar.js, clarifying that a future
version could improve this code by modifying
EmojiPickerDropdown.
Status reactions had an API similar to that of
announcement reactions, using PUT and DELETE at a
single endpoint. I believe that for statuses, it
makes more sense to follow the convention of the
other interactions and use separate POST endpoints
for create and destroy respectively.
Turns out the strange error where it would delete
the wrong reaction occurred because I forgot to
pass the emoji name to the query, which resulted
in the database deleting the first reaction it
found. Also, this removes the unused set_reaction
callback and includes the Authorization module for
the status reactions controller.
Reactions will be backported to the vanilla
flavour, which requires all related settings to
be accessible from the vanilla settings page
rather than the glitch specific settings modal.
