Implement minimal EIP 1102 support

[danfinlay]

For some reason some tests have broken, and I can't tell why. Opening a PR so someone else could take a look maybe. I'll try to chip away at this as time allows.

This minimal version of EIP 1102 support simply requests user login when the component loads.

Another, more nuanced approach would be to show a login widget that allows users to deliberately login if they want, or to remain anonymous and continue using the page.

I have a basic implementation of that on another branch.

Fixes #35

[czxtm]

Awesome, I'll look into the test cases.

On another note, reading the EIP, I noticed that Provider#enable is already deprecated in favor of eth_requestAccounts RPC call - should this also be implemented? See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1102.md#providerenable-deprecated

[czxtm]

Hey @danfinlay ,

Maybe why the test broke is because the provider relies on both a synchronous and asynchronous method for getting the current accounts. It tries to populate in a synchronous manner and falls back to asynchronous.

My understanding from the EIP is that accounts will no longer be available by default synchronously, which is fine. My question is, after the user has authorized a dApp, does this spec specify if the account is stored in an accessible place in memory afterwards.

For example, in web3 v1, once the user has signed in I can access web3.eth.accounts.wallet[0]. Will this still be the case in metamask with currentProvider.enable()?

[czxtm]

Actually nevermind. I think it's just weird async issues in enzyme

[czxtm]

Fixed the tests. thank you

[czxtm]

Published on npm: react-web3@1.2.0