The `ganache.js` helper module uses `ganache-core` to start `ganache`
instead of `ganache-cli`, and allows all of the same customization.
Using `ganache` programmatically from our e2e tests is much faster, as
we don't have to wait that arbitrary 5 seconds before each test as we
wait for `ganache-cli` to start up.
* Add `react/no-unused-prop-types` rule
All detected unused prop types have been removed. I have attempted to
ensure these props are no longer passed in either.
* Update handling of props to avoid false positive lint errors
These cases were detected by `react/no-unused-prop-types` as being
unused props, even though they were used. These minor adjustments
prevent them from being flagged as errors.
* Update unit tests
Many of these tests were just checking that specific props were passed
from containers or to a child component. These were deleted, as I can't
imagine how they'd be useful.
* Disable `react/no-unused-prop-types` in `componentWillReceiveProps
The rule `react/no-unused-prop-types` doesn't seem to be detecting
props used within `UNSAFE_componentWillReceiveProps`. The two cases
have been disabled temporarily until we can replace these unsafe
lifecycle functions.
* Use arrow property initializer functions
* Use pure components where applicable
* Add UNSAFE_ prefix for deprecated lifecycle hooks
* Add allow UNSAFE_
* Removed unused "Component"
* Replace boron with 'fade-modal'
* Upgrade react/no-deprecated to an error
* Paste react-tooltip-component source directly
* Use arrow functions to bind `this`
* Add UNSAFE_ prefix
* Update react-redux, react-router-dom
* Remove things from inlined 'fade-modal'
* Adjust mountWithRouter to get unit tests passing again
* Remove domkit
* Add Wrapper to render-helpers
* Upgrade @storybook/addon-knobs
This rule prevents using an async function as a Promise executor (e.g.
as the argument to a `Promise` constructor). This pattern is usually a
mistake because it implies that the Promise constructor was not
necessary in the first place. It also makes error handling difficult,
as any errors thrown would be uncaught unless you wrap the body in a
try/catch block.
The connect route now takes a route parameter: the permissions request
id. This id is set whenever the permissions connect screen is opened,
ensuring that that tab is for that specific request alone.
This makes handling of multiple permissions requests a bit more
intuitive. Previously whenever opening multiple permissions requests,
the first one would be shown on each successive tab, whereas you
would expect each tab to show the request that prompted the tab to
open. Users may now address permissions request in whichever order
they'd like to, rather than being forced to deal with them
chronologically.
The prop `prevIsAccountMenuOpen` was referenced in `prevProps`, despite
it not existing. It seems clear from the context that the intention
was to check the `isAccountMenuOpen` prop from `prevProps`, and name
the local variable `prevIsAccountMenuOpen`.
* Ensures the tx controller + tx-state-manager orders transactions in the order they are received
* Handle transaction ordering in cases where tx ids are off by more than 1 in tx-state-manager
* Add comment to addUnapprovedTransaction explaining calling _determineTransactionCategory after generateTxMeta
* Sort txes by timestamp of creation instead of id
The MetaMask logo was throwing an exception because the `history` prop
from React Router wasn't being passed in. However, even if it was
passed in, clicking on the logo wouldn't have done anything because the
home route redirects back to the permission connect page.
Instead the logo now isn't given an `onClick` handler. The
`MetaFoxLogo` component has been updated to only set `cursor: pointer`
if given an `onClick` handler.
Attempts to approve or reject a permissions request that is no longer
pending will now emit a warning instead of throwing an exception.
I _think_ this can happen by clicking 'Submit' on the Permission
Connect screen twice, though I've been unable to reproduce that. I know
that it can be done if using multiple windows though. While it is
possible we have a UI bug somewhere (e.g. maybe we're not preventing
'Submit' from being clicked twice), I don't think it's possible to
eliminate the chance of this happening altogether, so we'd best prepare
for it.
There were a few older actions that were written such that they assumed
`this` referred to the `actions` object. That assumption no longer held
as of #7561. These actions have been updated to refer directly to the
actions object instead.
* origin/develop:
Fix SimpleDropdown event bubbling (#7627)
Remove unneeded store connections (#7625)
Replace wild random number key with index (#7629)
Use ES6 exports for selectors (#7626)
Fix a typo made comparing previous prop (#7628)
Connect distinct accounts per site (#7004)
eslint: Enable more react/jsx-* rules (#7592)
Enable react/no-unused-state rule for ESLint (#7609)
Enable no-var rule for ESLint (#7590)
Process URL fragment for ens-ipfs redirects (#7604)
add locale fix script (#7580)
Prevent redux state mutation (#7598)
The prop `prevIsAccountMenuOpen` was referenced in `prevProps`, despite
it not existing. It seems clear from the context that the intention
was to check the `isAccountMenuOpen` prop from `prevProps`, and name
the local variable `prevIsAccountMenuOpen`.
Whymarrh Whitby
Mark Stacey
ricky
MetaMask Bot
Xavier Maysonnave
Dan J Miller
ryanml
Bruno Barbieri
Thomas
Frankie
Dan Finlay
Thomas Huang
Paweł Lula