Conversation
f4cd352 to
cbca6d5
Compare
shared/constants/transaction.js
Outdated
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
shared/constants/transaction.js
Outdated
There was a problem hiding this comment.
It might be worth clarifying that these are just the interactions that we haven't special-cased. approve is a contract interaction as well.
shared/constants/transaction.js
Outdated
There was a problem hiding this comment.
Should "confirmed" and "failed" be represented here as well?
There was a problem hiding this comment.
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.
3c0f25f to
4b84245
Compare
Builds ready [4b84245]
Page Load Metrics (613 ± 73 ms)
|
4b84245 to
d5e89a2
Compare
6222cd3 to
530a83b
Compare
Builds ready [530a83b]
Page Load Metrics (404 ± 51 ms)
|
Builds ready [9e90446]
Page Load Metrics (404 ± 59 ms)
|
9e90446 to
69787a0
Compare
Builds ready [69787a0]
Page Load Metrics (434 ± 57 ms)
|
a7dcf7f to
1931c06
Compare
Builds ready [1931c06]
Page Load Metrics (434 ± 57 ms)
|
4106748 to
bb89e98
Compare
Builds ready [bb89e98]
Page Load Metrics (462 ± 69 ms)
|
|
@Gudahtt I think this is ready for another review |
bb89e98 to
67d5208
Compare
Builds ready [67d5208]
Page Load Metrics (674 ± 94 ms)
|
67d5208 to
24a5ee3
Compare
|
@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. |
Builds ready [24a5ee3]
Page Load Metrics (436 ± 62 ms)
|
There was a problem hiding this comment.
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!
Builds ready [1e7048b]
Page Load Metrics (526 ± 107 ms)
|
Thanks @rekmarks Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
1e7048b to
018b35b
Compare
|
@rekmarks thanks for the suggestion to export objects with keys instead of individual variables. It worked out so well and now, by using |
rekmarks
left a comment
There was a problem hiding this comment.
Great work with the typings. LGTM! 🙌
Builds ready [018b35b]
Page Load Metrics (479 ± 70 ms)
|
Gudahtt
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Typo here (SIGNED should be SUBMITTED)
| status === TRANSACTION_STATUS_CONFIRMED && | ||
| type === TRANSACTION_TYPE_CANCEL | ||
| status === TRANSACTION_STATUSES.CONFIRMED && | ||
| type === TRANSACTION_TYPES.CANCEL |
There was a problem hiding this comment.
The hard-coded failed and cancelled values returned here should be using the constants as well
There was a problem hiding this comment.
We should use these constants in tx-state-manager as well 🤔 That's where the status returned below is set.
|
@Gudahtt i'll fix these today! Thanks for pointing them out |

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.