status-desktop/ui/imports/shared/popups/walletconnect/DAppSignRequestModal.qml

193 lines
6.9 KiB
QML
Raw Normal View History

import QtQuick 2.15
import QtQuick.Layouts 1.15
import QtQml.Models 2.15
import StatusQ 0.1
import StatusQ.Controls 0.1
import StatusQ.Core 0.1
import StatusQ.Core.Theme 0.1
import StatusQ.Core.Utils 0.1 as SQUtils
import AppLayouts.Wallet.popups 1.0
import AppLayouts.Wallet.panels 1.0
import shared.popups.walletconnect.panels 1.0
import utils 1.0
SignTransactionModalBase {
id: root
required property bool signingTransaction
// DApp info
required property url dappUrl
required property url dappIcon
required property string dappName
// Payload to sign
required property string requestPayload
// Account
required property color accountColor
required property string accountName
required property string accountEmoji
required property string accountAddress
// Network
required property string networkName
required property string networkIconPath
// Fees
required property string fiatFees
required property string cryptoFees
required property string estimatedTime
required property bool hasFees
property bool enoughFundsForTransaction: true
property bool enoughFundsForFees: false
refactor: Remove business logic from WC ui components 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.
2024-10-03 18:15:24 +00:00
signButtonEnabled: (!hasFees) || enoughFundsForTransaction && enoughFundsForFees
title: qsTr("Sign Request")
subtitle: SQUtils.StringUtils.extractDomainFromLink(root.dappUrl)
headerIconComponent: RoundImageWithBadge {
imageUrl: root.dappIcon
width: 40
height: 40
}
gradientColor: Utils.setColorAlpha(root.accountColor, 0.05) // 5% of wallet color
headerMainText: root.signingTransaction ? qsTr("%1 wants you to sign this transaction with %2").arg(root.dappName).arg(root.accountName)
: qsTr("%1 wants you to sign this message with %2").arg(root.dappName).arg(root.accountName)
fromImageSmartIdenticon.asset.name: "filled-account"
fromImageSmartIdenticon.asset.emoji: root.accountEmoji
fromImageSmartIdenticon.asset.color: root.accountColor
fromImageSmartIdenticon.asset.isLetterIdenticon: !!root.accountEmoji
toImageSmartIdenticon.asset.name: Theme.svg("sign")
toImageSmartIdenticon.asset.bgColor: Theme.palette.primaryColor3
toImageSmartIdenticon.asset.width: 24
toImageSmartIdenticon.asset.height: 24
toImageSmartIdenticon.asset.color: Theme.palette.primaryColor1
infoTagText: qsTr("Only sign if you trust the dApp")
infoTag.states: [
State {
name: "insufficientFunds"
refactor: Remove business logic from WC ui components 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.
2024-10-03 18:15:24 +00:00
when: root.hasFees && !root.enoughFundsForTransaction
PropertyChanges {
target: infoTag
asset.color: Theme.palette.dangerColor1
tagPrimaryLabel.color: Theme.palette.dangerColor1
backgroundColor: Theme.palette.dangerColor3
bgBorderColor: Theme.palette.dangerColor2
tagPrimaryLabel.text: qsTr("Insufficient funds for transaction")
}
}
]
showHeaderDivider: !root.requestPayload
leftFooterContents: ObjectModel {
RowLayout {
Layout.leftMargin: 4
spacing: Theme.bigPadding
ColumnLayout {
spacing: 2
StatusBaseText {
text: qsTr("Max fees:")
color: Theme.palette.baseColor1
font.pixelSize: Theme.additionalTextSize
}
StatusTextWithLoadingState {
Layout.fillWidth: true
objectName: "footerFiatFeesText"
text: formatBigNumber(root.fiatFees, root.currentCurrency)
refactor: Remove business logic from WC ui components 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.
2024-10-03 18:15:24 +00:00
loading: root.feesLoading && root.hasFees
customColor: !root.hasFees || root.enoughFundsForFees ? Theme.palette.directColor1 : Theme.palette.dangerColor1
elide: Qt.ElideMiddle
Binding on text {
when: !root.hasFees
value: qsTr("No fees")
}
}
}
ColumnLayout {
spacing: 2
visible: root.hasFees
StatusBaseText {
text: qsTr("Est. time:")
color: Theme.palette.baseColor1
font.pixelSize: Theme.additionalTextSize
}
StatusTextWithLoadingState {
objectName: "footerEstimatedTime"
text: root.estimatedTime
loading: root.feesLoading
}
}
}
}
// Payload
ContentPanel {
Layout.fillWidth: true
Layout.fillHeight: true
Layout.bottomMargin: Theme.bigPadding
payloadToDisplay: root.requestPayload
visible: !!root.requestPayload
}
// Account
SignInfoBox {
Layout.fillWidth: true
Layout.bottomMargin: Theme.bigPadding
objectName: "accountBox"
caption: qsTr("Sign with")
primaryText: root.accountName
secondaryText: SQUtils.Utils.elideAndFormatWalletAddress(root.accountAddress)
asset.name: "filled-account"
asset.emoji: root.accountEmoji
asset.color: root.accountColor
asset.isLetterIdenticon: !!root.accountEmoji
}
// Network
SignInfoBox {
Layout.fillWidth: true
Layout.bottomMargin: Theme.bigPadding
objectName: "networkBox"
caption: qsTr("Network")
primaryText: root.networkName
icon: root.networkIconPath
}
// Fees
SignInfoBox {
Layout.fillWidth: true
Layout.bottomMargin: Theme.bigPadding
objectName: "feesBox"
caption: qsTr("Fees")
primaryText: qsTr("Max. fees on %1").arg(root.networkName)
secondaryText: " "
enabled: false
visible: root.hasFees
components: [
ColumnLayout {
spacing: 2
StatusTextWithLoadingState {
objectName: "fiatFeesText"
Layout.alignment: Qt.AlignRight
text: formatBigNumber(root.fiatFees, root.currentCurrency)
horizontalAlignment: Text.AlignRight
font.pixelSize: Theme.additionalTextSize
loading: root.feesLoading
customColor: root.enoughFundsForFees ? Theme.palette.directColor1 : Theme.palette.dangerColor1
}
StatusTextWithLoadingState {
objectName: "cryptoFeesText"
Layout.alignment: Qt.AlignRight
text: formatBigNumber(root.cryptoFees, Constants.ethToken)
horizontalAlignment: Text.AlignRight
font.pixelSize: Theme.additionalTextSize
customColor: root.enoughFundsForFees ? Theme.palette.baseColor1 : Theme.palette.dangerColor1
loading: root.feesLoading
}
}
]
}
}