Previously all browser globals were allowed to be used anywhere by
ESLint because we had set the `env` property to `browser` in the ESLint
config. This has made it easy to accidentally use browser globals
(e.g. #8338), so it has been removed. Instead we now have a short list
of allowed globals.
All browser globals are now accessed as properties on `window`.
Unfortunately this change resulted in a few different confusing unit
test errors, as some of our unit tests setup assumed that a particular
global would be used via `window` or `global`. In particular,
`window.fetch` didn't work correctly because it wasn't patched by the
AbortController polyfill (only `global.fetch` was being patched).
The `jsdom-global` package we were using complicated matters by setting
all of the JSDOM `window` properties directly on `global`, overwriting
the `AbortController` for example.
The `helpers.js` test setup module has been simplified somewhat by
removing `jsdom-global` and constructing the JSDOM instance manually.
The JSDOM window is set on `window`, and a few properties are set on
`global` as well as needed by various dependencies. `node-fetch` and
the AbortController polyfill/patch now work as expected as well,
though `fetch` is only available on `window` now.
* Various component tests and some conditional statements
Conditional in account-menu in removeAccount when keyring sometimes is not initially provideed
Conditional on unlock-page when there is no target.getBoundingClientRect on the element.
* Update helpers
* Remove component debugging
* Add default params for render helpers
* Remove stubComponent for old Mascot
Changes in https://github.com/MetaMask/metamask-extension/pull/7893 has prevented the need to stub it out.
Change logout to lock in account-menu test
Unhandled rejections are now caught using built-in Node.js APIs instead
of with `bluebird`. `bluebird` was added as a production dependency but
was only used for this purpose. The code responsible for catching
unhandled rejection in the browser was removed, as this test helper is
never run in the browser.
Additionally, unhandled rejections are tracked over the course of all
tests, and result in a non-zero exit code if they remain at the end.
This was done because it is possible for errors to trigger the
`uncaughtRejection` event but then still be handled later on. This is
uncommon, and doesn't seem to happen in our test suite. But if it does
in the future, it'll be logged but won't result in a non-zero exit
code.
* 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
* Adds 4byte registry fallback to getMethodData() (#6435)
* Adds fetchWithCache to guard against unnecessary API calls
* Add custom fetch wrapper with abort on timeout
* Use opts and cacheRefreshTime in fetch-with-cache util
* Use custom fetch wrapper with timeout for fetch-with-cache
* Improve contract method data fetching (#6623)
* Remove async call from getTransactionActionKey()
* Stop blocking confirm screen rendering on method data loading, and base screen route on transactionCategory
* Remove use of withMethodData, fix use of knownMethodData, in relation to transaction-list-item.component
* Load data contract method data progressively, making it non-blocking; requires simplifying conf-tx-base lifecycle logic.
* Allow editing of gas price while loading on the confirm screen.
* Fix transactionAction component and its unit tests.
* Fix confirm transaction components for cases of route transitions within metamask.
* Only call toString on id if truthy in getNavigateTxData()
* Fix knownMethodData retrieval and data fetching from fourbyte
Abstract all configuration data into a singleton called `configManager`, who is responsible for reading and writing to the persisted storage (localStorage, in our case).
Uses my new module [pojo-migrator](https://www.npmjs.com/package/pojo-migrator), and wraps it with the `ConfigManager` class, which we can hang any state setting or getting methods we need.
By keeping all the persisted state in one place, we can stabilize its outward-facing API, making the interactions increasingly atomic, which will allow us to add features that require restructuring the persisted data in the long term without having to rewrite UI or even `background.js` code.
All the restructuring and data-type management is kept in one neat little place.
This should make it very easy to add new configuration options like user-configured providers, per-domain vaults, and more!
I know this doesn't seem like a big user-facing feature, but we have a big laundry list of features that I think this will really help streamline.
Also added the hdPath that Christian had told me to our calls to the LightWallet, but this does not seem to have made us generate the same accounts as `testrpc` yet.
