Skip to content

add shared transaction constants#9459

Merged
brad-decker merged 5 commits intodevelopfrom
unify-transaction-constants
Nov 3, 2020
Merged

add shared transaction constants#9459
brad-decker merged 5 commits intodevelopfrom
unify-transaction-constants

Conversation

@brad-decker
Copy link
Contributor

Description

Unifies and codifies that disparate constants used in various places through the app. We had some consts exported from the background that we used in the UI and some in the UI imported by the background.

this adds a 'shared' folder at the root that can hold within it any utilities, constants, etc that we want to share between the two code bases.

@brad-decker brad-decker force-pushed the unify-transaction-constants branch from f4cd352 to cbca6d5 Compare September 23, 2020 20:22
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In an ideal world, these would not be included here. I don't think we should call anything a "transaction" that is not a transaction, in the code or the UI. It's unfortunate that this is how the signature requests were integrated. This is responsible for a lot of existing complicated UI logic.

It would seem more appropriate to have a higher-level abstraction (e.g. "activity"), something that could be either a transaction or a signature request/signing, or something else. The set of things we want to show in the activity tab.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Although at this point in the code the things that get returned from nonceSortedTransactionSelector are called TransactionGroup, I intend on changing that in a future PR and updating these to reflect that. Also ideally I'll at some point move this logic into a background controller, enabling things like real pagination of activity, and that would make these variables -- whatever they end up being called -- make sense in a shared constant file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be worth clarifying that these are just the interactions that we haven't special-cased. approve is a contract interaction as well.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this comment addressed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should "confirmed" and "failed" be represented here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could but these are the statuses that don't exist as transaction statuses. Honestly i could go either way with it. If we had separate consts for those it would enable us to change the string value for one without changing the other in the future. These two cases here represent areas where we override the status by inferring from the transaction data. For example, pending happens when the transaction is in one of the mentioned statuses, and cancelled happens when a cancel type transaction has been confirmed... the others are just inherited from the primary transaction.

@brad-decker brad-decker force-pushed the unify-transaction-constants branch 2 times, most recently from 3c0f25f to 4b84245 Compare September 24, 2020 19:29
@metamaskbot
Copy link
Collaborator

Builds ready [4b84245]
Page Load Metrics (613 ± 73 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint30111462010
domContentLoaded38086561115273
load38186761315273
domInteractive38086461115273

@brad-decker brad-decker marked this pull request as ready for review September 24, 2020 22:22
@brad-decker brad-decker requested review from a team and kumavis as code owners September 24, 2020 22:22
@brad-decker brad-decker force-pushed the unify-transaction-constants branch from 4b84245 to d5e89a2 Compare October 7, 2020 15:49
@brad-decker brad-decker requested a review from danjm October 7, 2020 15:55
@brad-decker brad-decker force-pushed the unify-transaction-constants branch 2 times, most recently from 6222cd3 to 530a83b Compare October 7, 2020 17:25
@metamaskbot
Copy link
Collaborator

Builds ready [530a83b]
Page Load Metrics (404 ± 51 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint299141178
domContentLoaded30766440210651
load30966640410651
domInteractive30766440210651

@metamaskbot
Copy link
Collaborator

Builds ready [9e90446]
Page Load Metrics (404 ± 59 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint308341136
domContentLoaded29160740312359
load29360840412359
domInteractive29160640212359

@brad-decker brad-decker force-pushed the unify-transaction-constants branch from 9e90446 to 69787a0 Compare October 9, 2020 16:36
@metamaskbot
Copy link
Collaborator

Builds ready [69787a0]
Page Load Metrics (434 ± 57 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint29533552
domContentLoaded29161843212057
load29361943411957
domInteractive29161743212057

@metamaskbot
Copy link
Collaborator

Builds ready [1931c06]
Page Load Metrics (434 ± 57 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint29105552311
domContentLoaded31373943212058
load31474043412057
domInteractive31373843212058

@brad-decker brad-decker requested a review from Gudahtt October 14, 2020 17:00
@brad-decker brad-decker force-pushed the unify-transaction-constants branch 2 times, most recently from 4106748 to bb89e98 Compare October 23, 2020 17:53
@metamaskbot
Copy link
Collaborator

Builds ready [bb89e98]
Page Load Metrics (462 ± 69 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint308039115
domContentLoaded30066746114469
load30166846214369
domInteractive29966746014469

@brad-decker
Copy link
Contributor Author

@Gudahtt I think this is ready for another review

@brad-decker brad-decker force-pushed the unify-transaction-constants branch from bb89e98 to 67d5208 Compare October 28, 2020 20:52
@metamaskbot
Copy link
Collaborator

Builds ready [67d5208]
Page Load Metrics (674 ± 94 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint33112632412
domContentLoaded36696567219694
load36897067419794
domInteractive36696467219694

@brad-decker brad-decker force-pushed the unify-transaction-constants branch from 67d5208 to 24a5ee3 Compare October 29, 2020 15:17
@brad-decker
Copy link
Contributor Author

@darkwing would you mind reviewing this, specifically that transactions selector file that you recently modified. I only updated the name of constants but it'd be good to get a thumbs up on it.

@brad-decker brad-decker requested a review from darkwing October 29, 2020 15:18
@metamaskbot
Copy link
Collaborator

Builds ready [24a5ee3]
Page Load Metrics (436 ± 62 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint318439115
domContentLoaded28463743512862
load28563943612862
domInteractive28363743412862

Copy link
Member

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some nits about documentation that I think are worthwhile, but otherwise I am very happy about this PR.

My one general piece of feedback is that I think it's more ergonomic to define objects of constants and then export that object, rather than adding multiple exports.

For example that'd allow us to do something like:

import { TRANSACTION_CATEGORIES } from '../shared/constants/transaction'
// ...
if (tx.category === TRANSACTION_CATEGORIES.SWAP) { /* ... */ }

Also, if you ever need a map of constant values, you already have it.

This is just a suggestion, and I won't block on it!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was this comment addressed?

@metamaskbot
Copy link
Collaborator

Builds ready [1e7048b]
Page Load Metrics (526 ± 107 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint2911250209
domContentLoaded285968524222107
load287969526223107
domInteractive285968524222107

rekmarks
rekmarks previously approved these changes Oct 30, 2020
Copy link
Member

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice!

@danjm danjm added this to the v8.1.next? milestone Nov 2, 2020
@brad-decker
Copy link
Contributor Author

@rekmarks thanks for the suggestion to export objects with keys instead of individual variables. It worked out so well and now, by using @typedef for the object declaration, we have very nice developer tooling in vscode:

image

Copy link
Member

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work with the typings. LGTM! 🙌

@metamaskbot
Copy link
Collaborator

Builds ready [018b35b]
Page Load Metrics (479 ± 70 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint32113532211
domContentLoaded30580047814570
load30780147914570
domInteractive30479947714570

@brad-decker brad-decker merged commit 026a06b into develop Nov 3, 2020
@brad-decker brad-decker deleted the unify-transaction-constants branch November 3, 2020 22:57
@github-actions github-actions bot locked and limited conversation to collaborators Nov 3, 2020
Copy link
Member

@Gudahtt Gudahtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Belated, but, LGTM!

I noticed a few things that can be addressed in a future PR (a typo, and a few places where these constants should be used instead of string literals)

* @property {'rejected'} REJECTED - The user has rejected the transaction in the
* MetaMask UI
* @property {'signed'} SIGNED - The transaction has been signed
* @property {'submitted'} SIGNED - The transaction has been submitted to network
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo here (SIGNED should be SUBMITTED)

status === TRANSACTION_STATUS_CONFIRMED &&
type === TRANSACTION_TYPE_CANCEL
status === TRANSACTION_STATUSES.CONFIRMED &&
type === TRANSACTION_TYPES.CANCEL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hard-coded failed and cancelled values returned here should be using the constants as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use these constants in tx-state-manager as well 🤔 That's where the status returned below is set.

@brad-decker
Copy link
Contributor Author

@Gudahtt i'll fix these today! Thanks for pointing them out

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants