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.
- clear search on close (AssetSelectorCompact)
- sectionProperty removed
- highlighting fixed in TokenSelectorPanel
- setCustom renamed to setSelection
- test data moved into Component object
This component is simpler version of TokenSelector, composed of the same
basic componets, useful when only assets are subject of selection.
Closes: #16234
- add a secondary "loading" state (`loadingWithText`), that is show the
loading indicator next to the text
- simplify the StatusBaseButton layout (esp. handling the overall
opacity/visibility)
- add a QML test suite; the code was becoming too complex and adding a
simple boolean prop was getting "dangerous"
- port the SwapModal to use the new `loadingWithText` property
Fixes#15313
1. Hiding DApps button on not supported wallet account selection
2. Filtering DApps in connected dApps list based on account selection
closes: #15589closes: #15647
- display additional beta information as a tooltip
- don't overlap the Beta badge with the unread msg indicator
- some minor cleanups & fixes
Fixes#15795Fixes#15929
- format Big decimal numbers correctly according to the current locale;
some precisions loss is tolerated here for the display purposes
- fixes wrong decimal separators in some places and aligns with the
standard in terms of number of decimals, as everywhere else in the app
Fixes#15612Fixes#15790
- This commit temporarily disables the MaxAmount button in the `SwapInputPanel` and `SendModal` components.
- The MaxAmount button will be reintroduced with the correct behavior in issue #15709 for the 2.31 release.
closes: #15710
The static url validation state `Pairing.errors.ok` was directly
responsible for the validation action in UX. With current change
the validation is now based on the pairing response. When the
pairing response is received the UX is validated and after half second
UX is moved to the approval process (`ConnectedDAppModal`)
Closes: #15591
- when we arrive to a point when all input params are empty, disable the
middle Exchange button
- add QML test for the Exchange button enabled/disabled state
Fixes#15751
Fixing a bug where the community name is not shown in the `Send` button
Get the collectible community name from the community model for community tokens. Otherwise default to community id.
+ Fix WalletFooter layout when the buttons text exceeds the available width
to squash: Fixing send on owner token - name
1. Show Send Button on wallet footer when all accounts is selected
2. Hide Send Button in collectibles context menu and collectibles details view when the collectible is not owned by the user
3. Disable the Send Button in collectibles context menu and collectibles details view when the collectible is soulbound
to squash: Fine tune send action on collectibles
to squash: Fine tune send on collectibles
to squash: Fine-tune collectibles
Compute max fees for transaction related requests and display the
results to user.
Also:
- Add helper to convert from hex (backend) to decimal (frontend) values.
- Add helper to convert from float gwei to hex wei
- Update tests to accommodate for the new dependencies.
Sourcing of account balances is not included therefore the transaction is
allowed to go through even if the account balance is insufficient. An error
will be generated by the backend in this case.
Updates: #15192