* updated snap install warning per designs, hotfix for popover component to remove box styles from it's scss file and introduce them as default props
* small fix
* ConnectedAccountsPermissions: convert to FC
* permissions: add usePermissionsDescriptions
- fix ConnectedAccountsPermissions eth_accounts i18n
* ConnectedAccountsPermissions: rm .component
from path
* ConnectedAccountsPermissions: fix toggleExpanded
ensure we change previous state value
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* add boxes to popover sections for custom css
* updated doc strings
* added default props
* render Boxes only if the props are not empty
* possible fix
* second fix
* removed prop check function, converted header, footer and div elements to Box components and updated storybook and readme.mdx
* remove non existing prop
* fixed export issue
* updated storybook
* ConnectedAccountsPermissions: convert to FC
* permissions: add usePermissionsDescriptions
- fix ConnectedAccountsPermissions eth_accounts i18n
* ConnectedAccountsPermissions: rm .component
from path
* ConnectedAccountsPermissions: fix toggleExpanded
ensure we change previous state value
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The library `@testing-library/user-event` has been updated to the
latest beta version, so that our unit tests better model real user
interactions. In particular, I found that previously the `paste` event
was missing the `clipboardData` API, so it was impossible to implement
any custom handling of paste events (which we will need in later PRs).
See the `v14.0.0-beta.1` release notes for a list of all breaking
changes [1]. The main change is that all methods now return Promises.
The `paste` method has also been dramatically simplified.
The unit tests have also been updated to reset all mocks before each
test. These tests don't have any shared mocks, but this is generally a
good practice, to ensure that tests don't develop accidental inter-
dependencies.
[1]: https://github.com/testing-library/user-event/releases/tag/v14.0.0-beta.1
After landing on Swap, a disclaimer of Smart Transactions appear, and an error on devTools shows the following: “invalid prop ‘type’ of value ‘ul’” supplied to ‘Typography’
After enabling Smart Transactions, an error on devTools shows the following: “invalid prop ‘smartTransactionsOptInSatus’ of type ‘boolean supplied to ‘SlippageButtons’
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
After landing on Swap, a disclaimer of Smart Transactions appear, and an error on devTools shows the following: “invalid prop ‘type’ of value ‘ul’” supplied to ‘Typography’
After enabling Smart Transactions, an error on devTools shows the following: “invalid prop ‘smartTransactionsOptInSatus’ of type ‘boolean supplied to ‘SlippageButtons’
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* Updating Box component and adding dark theme to storybook toolbar
* Updating box props table manually
* Fixing linting issues
* Updating design-tokens to v.1.3.0
* Reverting theme/background changes in .storybook/preview.js so we can use implementation in #13651
* Updating yarn.lock
* Updating titles
We would like to insert TypeScript into the ESLint configuration, and
because of the way that the current config is organized, that is not
easy to do.
Most files are assumed to be files that are suited for running in a
browser context. This isn't correct, as we should expect most files to
work in a Node context instead. This is because all browser-based files
will be run through a transpiler that is able to make use of
Node-specific variables anyway.
There are a couple of important ways we can categories files which our
ESLint config should be capable of handling well:
* Is the file a script or a module? In other words, does the file run
procedurally or is the file intended to be brought into an existing
file?
* If the file is a module, does it use the CommonJS syntax (`require()`)
or does it use the ES syntax (`import`/`export`)?
When we introduce TypeScript, this set of questions will become:
* Is the file a script or a module?
* If the file is a module, is it a JavaScript module or a TypeScript
module?
* If the file is a JavaScript module, does it use the CommonJS syntax
(`require()`) or does it use the ES syntax (`import`/`export`)?
To represent these divisions, this commit removes global rules — so now
all of the rules are kept in `overrides` for explicitness — and sets up
rules for CommonJS- and ES-module-compatible files that intentionally do
not overlap with each other. This way TypeScript (which has its own set
of rules independent from JavaScript and therefore shouldn't overlap
with the other rules either) can be easily added later.
Finally, this commit splits up the ESLint config into separate files and
adds documentation to each section. This way sets of rules which are
connected to a particular plugin (`jsdoc`, `@babel`, etc.) can be easily
understood instead of being obscured.
* Add design-tokens and apply colors to button
* swap more colors
* tweak button and add dark theme switch to storybook
* tweak buttons
* fix typo
* remove comments
* add dep to ignored list
* fix linting issue
* fix linting issues
* Updating some styles and removing some deprecated buttons (#13742)
* Updating some styles and removing some deprecated buttons
* Warning button fixes
* Fixing warning text for darkmode
* bump design tokens and update storybook theme strategy
Co-authored-by: George Marshall <george.marshall@consensys.net>