[WIP] Add Issue/Comment Reactions #490
No reviewers
Labels
No Label
Priority-high
Accepting-merge-requests
API
API-dependency
Backport
Blocked
Brainstorming
Breaking
Bug
Changelog
CI
Cleanup
Confirmed
Discussion
Documentation
Duplicate
Enhancement
External-dependecy
F-droid
Feature
Google-play
Improvement
Invalid
Investigate
LGTM-done
LGTM-need
Long-term
Major-release
Minor-release
Needs-cleanup
Needs-feedback
Needs-help
Priority-critical
Priority-low
Priority-medium
Question
Ready
Refactor
Regression
Release
Repository
Security
Suggestion
Support
Testing
Translation
UI/UX
Upstream
Website
WIP
No Milestone
3 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gitnex/GitNex#490
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "(deleted):layout-reactions"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #73
[WIP] Adding layout for reactions.to [WIP] Adding layouts for reactions.ref: https://github.com/go-gitea/gitea/issues/11348
and https://github.com/go-gitea/gitea/issues/11330
How this conversion API is going to work? trying to understand it. Will it be called for every emoji to convert to utf?
@mmarif it depends on how we define it :)
but if we use it to render a text with emoji alias to a text with utf8 we should have a look at
https://try.gitea.io/api/swagger#/miscellaneous/renderMarkdown and https://try.gitea.io/api/swagger#/miscellaneous/renderMarkdownRaw
So, if we need a rendered md data. We 1st need let's say a comment data and then send that to another API to return rendered data. Many comments, many double calls?
I feel if we use the current Android library md renderer is better as it is native and we don't need extra http calls.
Feel free to correct me here if I am getting this wrong. But at the end I would suggest we keep rendering of the md, emoji in the app itself.
@mmarif sure I also like to render it localy <- will have benefits at caching via roomDB later too, but reaction api at the moment only support alias like
:tada:
but not the utf8 equifaltent, so it only should create an api call if we have to resolve a new alias to utf8 to display it as reaction option. I also will have a look at preparing the reaction api to accept utf8[WIP] Adding layouts for reactions.to Adding layouts for reactions.Adding layouts for reactions.to Add Issue/Comment ReactionsAdd Issue/Comment Reactionsto [WIP] Add Issue/Comment Reactions