This commit brings a separation of concerns for the UI components involved in dApp interactions.
Issue: The UI components depend on the WalletConnectService and also on its dependencies like DAppsRequestHAndler. As a result the UI components have a hard dependency on the WalletConnect specifics and are incompatible with BC. This results in duplication of logic.
Issue: The UI components operate on WalletConnect specific JSON object. E.g. session objects, session proposal etc. As a result the UI is built around the WalletConnect message format.
Issue: The UI components operate on ListModel items received through functions and stored internally. Any change in the model would result in a crash.
Solution: Remove the WalletConnectService dependency from DAppsWorkflow. The DAppsWorkflow now operates with models, signals and functions. This is the first step in the broader refactoring. Moving the logic into the service itself will allow us to further refactor the WC and BC.
How does it work now:
Dependencies - The UI components have a dependency on models. SessionRequestsModel and DAppsModel.
Pairing - The pairing is initiated in the UI. On user input a pairingValidationRequested signal is emitted and the result is received as a function pairingValidated. If the url is valid the UI requests a pairingRequested. When the WalletConnectService is refactored we can go further and request only pairingRequested and to receive a pairingResult call as a function with the result. In the current implementation on pairingRequested we'll receive a connectDApp request.
Connecting dApps - The flow is initiated with connectDApp function. This call currently contains all the needed info as args. In the next step it could be replaced with a ConnectionRequests model. The connectDApp call triggered a connection popup if we're not currently showing one to the user. If we're currently showing one it will be queued (corner case). The connection can be accepted with connectionAccepted and rejected with connectionDeclined. Once the connection is accepted we're expecting a result connectionSuccessful or connectionFailed. The connectionSuccessful also expects a new id for the established connection.
Signing - The signing flow orbits around the SessionRequestsModel. Each item from the model will generate a popup showing the sign details to the user. Sign can be accepted or rejected using signRequestAccepted or signRequestRejected. No response is currently expected. The model is expected to remove the sign request item.
Initial separation of backend-independ and stateless content
from backend-dependent method/properties which are a subject
of further refactors.
Closes: #16481
- hide the permission from the `PermissionsRow` when it's set to private
and the conditions are not met
- display a tooltip "(Not) eligible to join" over the lock icon
- show the same info in both community portal and profile dialog's
community showcase tab
- speedup searching/filtering in the community portal
- fixup and extend the SB pages to demonstrate the new behavior
Fixes#14747
- according to the Figma designs; looks much better now in both
small/big views
- don't stretch the bottomRow component unnecessarily in the Loader;
provide implicit width for the tags container instead
Based on changes done in this PR https://github.com/status-im/status-go/pull/5807
we can simplify our client logic a lot.
This results in the removal of many lines of code that are no longer needed
Closes 2nd part of #16336
- restore previous context menu item spacing (ColumnLayout has an
implicit spacing of 5)
- don't wrap the MessageReactionsRow into an extra Item container; fixes
the emoji reactions row being garbled
- enhance the SB page so that the above can be seen/tested there and
rename it to match the component name
- some smaller cleanups
Fixes#16409
Fixes#15750
When the pairing fails, the UI now let's the user use the seed phrase instead.
When they do, a call is send to the original device and both instances will show an AC notif.
When the original device accepts the pairing, the call is made to pair and sync the devices and the AC notifs get deleted
- excludes logic of resolving preferred display name to shared
contacts_utils
- expose PreferredDisplayName role from user_model
- improves PreferredDisplayName handling in member_model
Closes: #16429
Based on changes done in this PR https://github.com/status-im/status-go/pull/5807
we can simplify our client logic a lot.
This results in the removal of many lines of code that are no longer needed
Closes 1st part of #16336
Alex Jbanca
Siddarth Kumar
Michał Cieślak
Igor Sirotin
Lukáš Tinkl
Anastasiya Semenkevich
Sale Djenic
Cuteivist
Jonathan Rainville