Separate taglines and emojis from GetSiteResponse, into their own paged endpoints

[dessalines]

Requirements

• Is this a feature request? For questions or discussions use https://lemmy.ml/c/lemmy_support
• Did you check to see if this issue already exists?
• Is this only a feature request? Do not put multiple feature requests in one issue.
• Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.
• Do you agree to follow the rules in our Code of Conduct?

Is your proposal related to a problem?

Currently, both taglines and emojis are coming back with GetSiteResponse, and returning the entire list. This is wasteful as these lists grow long, and fetching taglines and emojis should be done with paged endpoints.

Describe the solution you'd like.

Create paged endpoints for taglines and emojis.

Describe alternatives you've considered.

NA

Additional context

NA

[fvanzee]

I've created a draft PR, which only adds the required new endpoints. I have some questions about breaking changes on the PR description.

[makotech222]

just bringing up the reason it was originally designed this way was because all users need the full list of emojis/taglines in order to display them properly in emoji picker/random tag line list, so there wasn't any reason to also pull them down in paged format for admin purposes. Just store them all the first time you visit site and you're good.

[dessalines]

I'm not sure how the emoji picker works, but if it sorts them by name or category, then it could also be a paged request, that loads after the picker shows up for that category. Its not scaleable or a good idea to have potentially thousands of emojis come back in the single response on every site load, better to use live-loading with searches like the user and community dropdowns.

[makotech222]

the emoji picker library is actually bugged: once you initialize it, you can't change the emoji list. Its a long standing bug that doesn't look like it will be fixed. Not our fault, but just something to be aware of if you try to paginate it. I can't imagine the Tribute inline component will also be easy to work with a paginated emoji list, since its searching after every key press == lots of network requests.

I think the smarter option is to version the emoji list, and only pull down the whole thing if your locally cached version is different.

[dessalines]

There are already examples of using tribute + network requests for users and communities, it'd be impossible to load them all like you're doing with the emoji picker. I'd say get tribute working first, then figure out if there's a way to incorporate network / async loading into the emoji picker, and if not, we'll need to use a different library.

[Nutomic]

#4580