With #669, we'll be tracking the server's list of Unicode emoji and names for them. Immediately after fetching server data with a registerQueue request, though, we won't yet have that data but will be going ahead and showing all the app's normal UI. See also #950.
As mentioned in #950, it's mostly fine to not have the data, because it only comes up in certain corners of the UI.
But if we wanted to partly close that gap, we could do something we do in zulip-mobile: we could hard-code into the app a baseline version of the same data, copied from some recent server version. Then up until the request to the server completes, we'd behave as if our baseline version were what the server actually has.
In zulip-mobile this behavior is necessary, or used to be necessary anyway, because the "server emoji data" protocol was new in server-6 (in 2022). Now in 2024, though, there's no need to support servers older than that (see #267 and #268); the only reason to have our own copy of the data would be for handling that transient state where we're still working on fetching it from the server. So in our initial implementation of #669 we'll skip this. We can add it later if experience tells us there's a need.
With #669, we'll be tracking the server's list of Unicode emoji and names for them. Immediately after fetching server data with a registerQueue request, though, we won't yet have that data but will be going ahead and showing all the app's normal UI. See also #950.
As mentioned in #950, it's mostly fine to not have the data, because it only comes up in certain corners of the UI.
But if we wanted to partly close that gap, we could do something we do in zulip-mobile: we could hard-code into the app a baseline version of the same data, copied from some recent server version. Then up until the request to the server completes, we'd behave as if our baseline version were what the server actually has.
In zulip-mobile this behavior is necessary, or used to be necessary anyway, because the "server emoji data" protocol was new in server-6 (in 2022). Now in 2024, though, there's no need to support servers older than that (see #267 and #268); the only reason to have our own copy of the data would be for handling that transient state where we're still working on fetching it from the server. So in our initial implementation of #669 we'll skip this. We can add it later if experience tells us there's a need.