* origin/develop: (210 commits)
Dark Mode: Remove unwanted background for price quote (#14278)
Dark Mode: Fix colors in toggle button (#14280)
Ensure proper color for swaps edit link (#14273)
Dark Mode: Ensure actionable message button colors are the same color as previously (#14271)
Add token standard to Token Added event. (#14253)
Token Aggregators component for Tokens Detected page (#14157)
Ensure Metafox follows cursor on Fetching quotes screen (#14261)
TransactionsControllerTest: catch uncaught errors (#14196)
GasModalPageContainer story: convert knobs and actions to controls / args (#13516)
Show STX switch for wrapping / unwrapping (#14225)
Change over ImportToken stories to use controls instead of knobs, update props in stories (#14246)
Change over FeeCard stories to use controls instead of knobs, update props in stories (#13766)
Update What's new screen with Token Detection information (#14124)
Improvements for multi-layer fee UX (#13547)
metaMetricsEvent -> trackEvent (#14249)
E2e dapp interactions (#14149)
failing contract interaction e2e (#14227)
Removed metrics event (#14042)
Add TypeScript to the build system (#13489)
Build user traits object when metamask state changes (#14192)
...
An array of integers is now used to represent the SRP in three cases:
* In the import wallet flow, the UI uses it to pass the user-provided
SRP to the background (which converts the array to a buffer).
* In the create wallet flow, the UI uses it to retrieve the generated
SRP from the background.
* When persisting the wallet to state, the background uses it to
serialize the SRP.
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
This PR changes over the deprecated knobs and actions in `fee-card.stories.js` to controls.
I attempted to create a `README.mdx`, but unfortunately the `<ArgsTable of={FeeCard} />` refused to render out any of the documentation comments I added to the `FeeCard.propTypes`, thus that has not been included (and no documentation has been added to the propTypes of FeeCard).
_Please note:_ currently nested arg types are not possible in StoryBook, but discussions are open: https://github.com/storybookjs/storybook/issues/11486. This means that the StoryBook shows `primaryFee`, `primaryMaxFee`, `secondaryFee` and `secondaryMaxFee`, but these are mapped to the 2 `primaryFee` and `secondaryFee` props of the component. This is visible if the developer clicks on the `Show code` button at the docs page in StoryBook.
Signed-off-by: Jurriaan Den Toonder <1493561+Fastjur@users.noreply.github.com>
* Show fiat on confirm screen on multilayer-fee network
* Disable gas editing on optimism
* Fix send max mode on optimism
* Represent layer 2 gas fee as a single value
* Hide gas fee edit UI on optimism
* Improvement multilayer-fee-message styling
* Lint fix
* Fix locales
* Remove unnecessary code change
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
* Connect to a second Dapp when MM is locked
* Refactored dapp server setup to allow multiple servers
* Triggering notification with MM locked
* Fix testcase description
* Fix lint
* Merge develop and remove extra line
* Updated baseport and included iselementPresent for a clearer assertion
* Fix lint issues
* Use Ganache pattern for defining number of Dapp servers
* Fix lint issues
This commit modifies the build system so that TypeScript files can be
transpiled into ES5 just like JavaScript files.
Note that this commit does NOT change the build system to run TypeScript
files through the TypeScript compiler. In other words, no files will be
type-checked at the build stage, as we expect type-checking to be
handled elsewhere (live, via your editor integration with `tsserver`,
and before a PR is merged, via `yarn lint`). Rather, we merely instruct
Babel to strip TypeScript-specific syntax from any files that have it,
as if those files had been written using JavaScript syntax alone.
Why take this approach? Because it prevents the build process from being
negatively impacted with respect to performance (as TypeScript takes a
significant amount of time to run).
It's worth noting the downside of this approach: because we aren't
running files through TypeScript, but relying on Babel's [TypeScript
transform][1] to identify TypeScript syntax, this transform has to keep
up with any syntax changes that TypeScript adds in the future. In fact
there are a few syntactical forms that Babel already does not recognize.
These forms are rare or are deprecated by TypeScript, so I don't
consider them to be a blocker, but it's worth noting just in case it
comes up later. Also, any settings we place in `tsconfig.json` will be
completely ignored by Babel. Again, this isn't a blocker because there
are some analogs for the most important settings reflected in the
options we can pass to the transform. These and other caveats are
detailed in the [documentation for the transform][2].
[1]: https://babeljs.io/docs/en/babel-plugin-transform-typescript
[2]: https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats
