frontend: utilize send-wrapper to lift some stuff from the Send component
#2955
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
NicolaLS
changed the title
Send component
thisconnect
requested changes
Oct 11, 2024
| @@ -31,7 +31,7 @@ export const ConfirmingWaitDialog = ({ | |||
| selectedUTXOs, | |||
| coinCode, | |||
| transactionDetails | |||
| }: Omit<TConfirmSendProps, 'device'>) => { | |||
| }: Omit<TConfirmSendProps, 'bb01Paired'>) => { | |||
There was a problem hiding this comment.
when you add bb01Paired to TConfirmSendProps you need to Omit it 2 times.
How about you remove it from TConfirmSendProps and add it only where needed, something like:
diff --git a/frontends/web/src/routes/account/send/components/confirm/confirm.tsx b/frontends/web/src/routes/account/send/components/confirm/confirm.tsx
index 5c1d5b05e..7b4d19451 100644
--- a/frontends/web/src/routes/account/send/components/confirm/confirm.tsx
+++ b/frontends/web/src/routes/account/send/components/confirm/confirm.tsx
@@ -30,8 +30,13 @@ type TFiatValueProps = {
amount: string
}
-export const ConfirmSend = (props: TConfirmSendProps) => {
- return (props.bb01Paired !== undefined ? (
+type ConfirmSend = { bb01Paired: boolean | undefined } & TConfirmSendProps;
+
+export const ConfirmSend = ({
+ bb01Paired,
+ ...props
+}: ConfirmSend) => {
+ return (bb01Paired !== undefined ? (
<ConfirmingWaitDialog
{...props}
/>
@@ -50,7 +55,7 @@ export const BB02ConfirmSend = ({
selectedUTXOs,
coinCode,
transactionDetails
-}: Omit<TConfirmSendProps, 'bb01Paired'>) => {
+}: TConfirmSendProps) => {
const { t } = useTranslation();
const {
diff --git a/frontends/web/src/routes/account/send/components/confirm/dialogs/confirm-wait-dialog.tsx b/frontends/web/src/routes/account/send/components/confirm/dialogs/confirm-wait-dialog.tsx
index 6235aea0e..9b8a27cec 100644
--- a/frontends/web/src/routes/account/send/components/confirm/dialogs/confirm-wait-dialog.tsx
+++ b/frontends/web/src/routes/account/send/components/confirm/dialogs/confirm-wait-dialog.tsx
@@ -31,7 +31,7 @@ export const ConfirmingWaitDialog = ({
selectedUTXOs,
coinCode,
transactionDetails
-}: Omit<TConfirmSendProps, 'bb01Paired'>) => {
+}: TConfirmSendProps) => {
const { t } = useTranslation();
const [signProgress, setSignProgress] = useState<TSignProgress>();
diff --git a/frontends/web/src/routes/account/send/components/confirm/types.ts b/frontends/web/src/routes/account/send/components/confirm/types.ts
index 6e288db04..dd280e389 100644
--- a/frontends/web/src/routes/account/send/components/confirm/types.ts
+++ b/frontends/web/src/routes/account/send/components/confirm/types.ts
@@ -27,7 +27,6 @@ export type TransactionDetails = {
}
export type TConfirmSendProps = {
- bb01Paired: boolean | undefined;
baseCurrencyUnit: ConversionUnit;
note: string;
hasSelectedUTXOs: boolean;| @@ -516,20 +501,16 @@ class Send extends Component<Props, State> { | |||
| </Column> | |||
| </Grid> | |||
| </ViewContent> | |||
|
|
|||
| {device && ( | |||
There was a problem hiding this comment.
With this ConfirmSend is always mounted, I think it is fine...
but I want to test this a bit.
There was a problem hiding this comment.
I could also change the meaning of bb01Paired: boolean | undefined to undefined == no device connected and then use true/false to check whether its a bb01 or bb02
There was a problem hiding this comment.
nvm, that does not work
Utilize the `SendWrapper` to get the mobile channel error, and (bb01) paired status in case a bb01 is connected. This simplifies the `Send` component and better distinguishes code for bb01/bb02 stuff.
NicolaLS
force-pushed
the
send-improvements-before-functional-refactor
branch
from
ca49784
to
e544037
Compare
Type `coinUnit` in `IAccount` to use `CoinUnit`.
NicolaLS
force-pushed
the
send-improvements-before-functional-refactor
branch
from
e544037
to
a03270f
Compare
thisconnect
requested changes
Oct 24, 2024
| @@ -25,12 +25,14 @@ import { TConfirmSendProps } from '@/routes/account/send/components/confirm/type | |||
| import { ConfirmingWaitDialog } from '@/routes/account/send/components/confirm/dialogs/confirm-wait-dialog'; | |||
| import style from './confirm.module.css'; | |||
|
|
|||
| type TConfimrSend = { bb01Paired: boolean | undefined } & TConfirmSendProps; | |||
There was a problem hiding this comment.
This landed in the wrong commit? Seems not related to "type coinUnit in IAccount "
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Two small improvements towards the functional refactor.
Two things:
bitbox-wallet-app/frontends/web/src/routes/account/send/send.tsx
Lines 134 to 137 in 9ed7888
Into the send-wrapper and I'm not so sure if that's a good idea. But imo. there is no point in showing the error/returning only when the user hits send, because that is the ultimate goal of the component anyways.
bb01Pairedinstead ofdevice(which was actuallyproduct) now to decide whether to show BB01 or BB02 stuff. This is a bit implicit but I think it is easy to understand/does not make the code harder to understand. Ofc. we can just add the device prop. back in if you think it is worth it.