Add Support for Emoji Reactions (Replaces #1980)#2127
Conversation
|
Not a review, but this reintroduces some of the deleted js locale files, which have been replaced with json files. |
|
Oops! Thought I fixed that in the rebase...
…On Wed, Mar 8, 2023 at 5:24 AM Plastikmensch ***@***.***> wrote:
Not a review, but this reintroduces some of the deleted js locale files,
which have been replaced with json files.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WHYUCJQHIREABXF4M23W3CCB5ANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Brian "Neatchee" Resnik
|
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
Highly suggest this e4c411e to be added. |
|
Ah, I messed that commit up. Apply 9c4e060 afterwards. |
Hmh. Maybe something went wrong while porting, but Edit: Not important anymore, since "e" doesn't cause any errors anymore |
|
Apologies if this should be obvious, as I'm not really a Ruby/React dev: I'm not sure if I agree with exposing this setting to the end-user. Certainly not without enforcing a server-supplied maximum value. I am generally opposed to any changes that will fragment user experience without a clear advantage to the end-user. This also increases the test surface area as we'll need to make sure nothing breaks visually across any of the UI - desktop and mobile - regardless of what the user sets this value to. Can you make a compelling argument for why a user would want to make fewer reactions visible? More than a single line of reactions visible? |
|
@neatchee this was part of the original patch, I merely ported it. |
|
Oh. Huh. Okay. I'll get it merged when I can
…On Mon, Apr 3, 2023, 3:28 PM Jeremy Kescher ***@***.***> wrote:
@neatchee <https://github.com/neatchee> this was part of the original
patch, I merely ported it.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH2OUIHQTCE5B27V6PDW7NFKNANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
ff157b2 to
59848e2
Compare
|
This pull request has resolved merge conflicts and is ready for review. |
|
This doesn't seem to work on Husky. I would like to be able to add emoji reactions from Husky. |
Husky has to implement the ability to add reactions. |
|
I think Husky has this ability - but since it's a fork of Tusky specifically for Pleroma, it would need adjustment for this PR. |
Yes, most likely they don't check Mastodon instances for availability of this feature. |
It doesn't check. It just displays the emoji reaction button on every post, on every instance. I was hoping that this PR could implement the endpoint that Husky uses for emoji reactions, for compatibility's sake. |
|
It is not the server's responsibility to implement the API as the client expects for another software's implementation. |
|
Would it be possible to implement the ability to see who reacted to a post? Not showing what users reacted with while also showing who boosted/liked a post can cause confusion in quite a few contexts. |
|
That has been discussed as a separate change. It's desired. Just not done
…On Sat, Apr 29, 2023, 8:45 PM Essem ***@***.***> wrote:
Would it be possible to implement the ability to see who reacted to a
post? Not showing what users reacted with while also showing who
boosted/liked a post can cause confusion in quite a few contexts.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH5LCXPHBCFFAQ4N7NDXDXN6LANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
Fedibird uses the value "emoji_reaction" in the "fedibird_capabilities" key in the "/api/v1/instance" response to notify the client of the feature |
Ah, it's missing the margin. // line 1034
&--in-thread {
border-bottom: 0;
.status__content,
.status__action-bar,
.reactions-bar {
margin-left: 46px + 10px;
width: calc(100% - (46px + 10px));
}
}(This also needs to be done in vanilla styles) |
|
There's a bug in this in which someone can react to a post that's not visible to them (for example, a blocked account) |
|
Couple questions about that:
* Via direct API call? Or also via UI if the user was blocked after seeing
the post?
* Does the user receive a notification that the blocked user reacted to
them?
Will need to think about ideal behavior in that scenario since a "post does
not exist" page isn't feasible
…On Sat, May 6, 2023, 9:24 PM Emma ***@***.***> wrote:
There's a bug in this in which someone can react to a post that's not
visible to them (for example, a blocked account)
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH3ND6FHJDMUANYVGNLXE4PYXANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes via the API, however I see no reason it wouldn't work via UI so long as the client hasn't received the updates that lead the post to disappear when blocked.
No.
The /:id/favourite and /:id/reblog endpoints return a 404 for any post you can't see, for any reason (block, post privacy, etc) - I assume that would be the behaviour to replicate here as well. |
|
oh ok. I see. The custom_emojis_controller commit was pulled in because it was apparently also missed on this side? As for broken version.rb that's just a mistake on my part during conflict resolution. Are there other commits you see in there that shouldn't? |
|
yeah, 34f9e54 should not be in this PR, either (because it was another Catstodon specific commit) Actually, it wasn't a bunch, it was mostly the same commit from multiple rebases being shown after each other lol. |
|
I'm not gonna deal with rewinding the log again >.> Just reverting. |
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
This pull request has resolved merge conflicts and is ready for review. |
There was a problem hiding this comment.
This is only a surface level review for now.
Gawd this one is too big and went through too many changes...
Another thing:
reaction should be added to NON_EMAIL_TYPES in app/services/notify_service.rb as e-mail notifications for reactions are currently not supported.
|
|
||
| class Api::V1::CustomEmojisController < Api::BaseController | ||
| vary_by '', unless: :disallow_unauthenticated_api_access? | ||
| skip_before_action :require_authenticated_user!, unless: :whitelist_mode? |
There was a problem hiding this comment.
Isn't this also a catstodon specific thing to allow anyone to copy custom emojis? (@kescherCode )
There was a problem hiding this comment.
Why is visibleReactions missing from this file?
There was a problem hiding this comment.
This file should have the .jsx extension (or better yet rewritten for .tsx)
| import AccountContainer from 'flavours/glitch/containers/account_container'; | ||
| import Spoilers from '../components/spoilers'; | ||
| import Icon from 'flavours/glitch/components/icon'; |
There was a problem hiding this comment.
visibleReactions is also missing here.
| @account.reacted?(original_status, name) | ||
|
|
||
| custom_emoji = nil | ||
| if name =~ /^:.*:$/ |
There was a problem hiding this comment.
| if name =~ /^:.*:$/ | |
| /^:.*:$/.match?(name) |
| return false if name.nil? | ||
|
|
||
| custom_emoji = nil | ||
| if name =~ /^:.*:$/ |
There was a problem hiding this comment.
| if name =~ /^:.*:$/ | |
| if /^:.*:$/.match?(name) |
| Fabricator(:status_reaction) do | ||
| account nil | ||
| status nil | ||
| name "MyString" | ||
| custom_emoji nil | ||
| end No newline at end of file |
There was a problem hiding this comment.
| Fabricator(:status_reaction) do | |
| account nil | |
| status nil | |
| name "MyString" | |
| custom_emoji nil | |
| end | |
| # frozen_string_literal: true | |
| Fabricator(:status_reaction) do | |
| account | |
| status | |
| name '👍' | |
| custom_emoji nil | |
| end |
At least making the fabricator usable.
There was a problem hiding this comment.
Hmh this seems to cause a failure:
1) The status_reaction factory is valid
Failure/Error: expect(factory).to be_valid
expected #<StatusReaction id: 1, account_id: 110339817053204859, status_id: 110339817053191929, name: "👍", custom_emoji_id: nil, created_at: "2023-05-09 17:06:33.686302000 +0000", updated_at: "2023-05-09 17:06:33.686302000 +0000"> to be valid, but got errors: Limit of different reactions reached
# ./spec/fabricators_spec.rb:9:in `block (3 levels) in <top (required)>'
There was a problem hiding this comment.
Hm, that's odd indeed. I'll not apply this for now.
There was a problem hiding this comment.
Yeah, I don't know how to fix that.
The fabricator itself works, it's just the fabricators_spec which fails
There was a problem hiding this comment.
This migration should only be needed for people who already merged this into their forks.
Though, that is basically everyone working on this ^^
|
This pull request has merge conflicts that must be resolved before it can be merged. |
|
Would either of you like to take over this PR? :) As mentioned above, I'm
not really a Ruby dev, I just wanted the feature and it was stagnant. Happy
to keep applying feedback but figured I'd offer it up :D
…On Tue, May 9, 2023, 11:22 AM Jeremy Kescher ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In app/controllers/api/v1/custom_emojis_controller.rb
<#2127 (comment)>:
> @@ -2,6 +2,7 @@
class Api::V1::CustomEmojisController < Api::BaseController
vary_by '', unless: :disallow_unauthenticated_api_access?
+ skip_before_action :require_authenticated_user!, unless: :whitelist_mode?
It is and should not be in here.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH4O7DIOQF6BWBPDN53XFKDOXANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I really shouldn't put more work upon myself, but I would be willing to take over. |
|
As I actively maintain this in my own fork, I'd be happy to take over. |
|
If @kescherCode can't take it, would it be easier on you if you provide
instruction and I implement to the best of my ability? Even if that means a
longer review? I don't mind at all, I just don't want to make this harder
than it needs to be
…On Tue, May 9, 2023, 11:53 AM Plastikmensch ***@***.***> wrote:
Would either of you like to take over this PR? :) As mentioned above, I'm
not really a Ruby dev, I just wanted the feature and it was stagnant. Happy
to keep applying feedback but figured I'd offer it up :D
I really shouldn't put more work upon myself, but I would be willing to
take over.
Already considered it when the old PR became stagnant.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WHZLKQNGR35L5OXCH7DXFKHCFANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I actually don't know, though it can be hard for me to give instructions sometimes. |
|
I won't really split this into backend and frontend because that would really mess with the history of the existing commits... |
Yeah... :/ |
|
One more migration that didn't belong here in the first place: |
|
We're off to PR number three. #2221 Closing this one out. <3 |

Originally #1980
This has been running in production without issue at https://urusai.social for several weeks now.
Urusai's repo is here: https://github.com/neatchee/mastodon