Update:
Problem with nested TouchableHighlight was solved, so now on desktop it is possible to open profiles from avatar in chat.
Also fixed lags in chat search box and removed context menu options and buttons that call actions specific for mobile, like “share”, “invite friends”, “scan qr code”
Context menu for chat messages now called by right mouse click.
Next step will be investigation of poor FlatList performance on desktop.
@volodymyr.kozieiev Thanks for this thread and the updates. Do you think we could create an issue in Github (possibly with multiple issues linked to it) that outlines the known steps to getting mobile UI into desktop? Any thoughts on rough timeline for doing this? With our without poor perf.
@oskarth, I’ll create an issue. Mobile UI already works, so without FlatList optimization I’d say it is not more than week needed to check/merge it with some additional fixes. As for FlatList - can’t say for sure, I don’t know where is the source of a problem yet.
FlatList performance investigation is in progress, so far no solution found.
To merge big and long-lasting PR@oskarth suggested to put all changes related to new UI under the flag. So PR was changed. By default it shows old desktop UI, but if MOBILE_UI_FOR_DESKTOP=1 specified in .env file, app runs mobile UI for desktop.
It is turned out that laggy behavior consist of at least two different issues.
First of them - long delays before dynamic loading next chunk of data. For this issue solution was found yesterday. There is discrepancy between mobile and desktop events flow. Desktop sends only one onScroll event per scroll and doesn’t trigger js implementation code as many times as it should.
Second issue - FlatList scroll position jumps when elements dynamically added to it while it scrolls. Will work on this right after fixes needed for mobile UI.
Having mobile UI on desktop seems like a good milestone to push marketing content about, even if it creates little material different for users. wdyt @jonathan@oskarth@volodymyr.kozieiev? Am I wrong about impact for users? Will there be any performance upsides?
And also, @volodymyr.kozieiev@andrey perhaps we can chat about implications for core UI, i.e. with mobile UI on desktop, how much easier is it to build for feature parity?
It’s a bit early, because at first, the Mobile UI won’t be the default. It would be a good step from the technical perspective (we actually have the same UI implementation for both platforms), but we’ll need to fix 2 column view before we will actually make a real switch and get rid of the separate Desktop UI.
Perhaps we can enlist some support from the community? If we communicate the fact that we are doing this and want to introduce the mobile UI on desktop, we can put up some issue & bounties and get people involved?
IMO - enlisting developer contribution is the best form of comms anyway.
I dont want to create more work for you all though so let me know if this is viable. If not, I can plan a different approach.
Idea about bounties is always good! But currently I don’t quite understand what task we can share with a community. We have 3 things to do: merge exisiting PR for mobile UI, improve FlatList performance, create 2-pane UI. And these tasks aren’t easily splittable into smaller ones to share with external contributors.
Probably it would be better to create bounties for fixes or desktop-specific UI features when at least minimal 2-pane UI is in place.
Mobile UI PR:
Few more regressions on mobile platforms were found yesterday that need to be fixed before merging mobile UI PR.
FlatList performance:
Latest profiling shown that scroll stuttering happens at the time of dynamic qml controls creation. I made that creation asynchronous and scroll fluidity is much better now. But there are still a lot of moments when FlatList shows blank spaces while controls loading. React Native documentation mentions blank spaces as a known tradeoff but anyway they shouldn’t happen that often.
Overall dynamic qml controls creation takes too much time. So I’m thinking on how to improve this.
Also I setup windows dev environment to check FlatList there and found out that it is buggier than on mac and crashes from time to time. So this platform needs additional attention
I agree, so far our experience with bounties was that polishing and bugfixing is the best way to at least get initial contributions (taking the initial dev env setup into account). So if there are few things to fix that aren’t urgent but it is good to have them fixed, we can make bounties.
For bigger tasks we aren’t there yet in terms of non-core contributors.
Just my suggestion: we could merge mobile UI first, and then just push our own flatlist implementation in status-react as a temporary solution ( i mean it will be the same component, but implementation inside will be different for desktop, simple one) , and then we could split 2-pane UI into small issues, i can help with it ,and bountify them
@andrey, we already have custom ScrollView implementation in react-native-desktop. And this implementation used in current desktop UI. It is far from ideal but better than current FlatList. If no quick improvements for FlatList found, we can use it.