eosconsequatur

web3-react Documentation

• Install
• web3-react Context
• web3-react@core API Reference
  • Web3ReactProvider
    • Props
    • Example
  • createWeb3ReactRoot
    • Arguments
    • Example
  • useWeb3React
    • Arguments
    • Example
  • getWeb3ReactContext
    • Arguments
    • Example
  • UnsupportedChainIdError
    • Example

Install

• Grab yourself a fresh copy of react@>=16.8
yarn add react@latest

• And then install web3-react
yarn add @web3-react/core@latest

web3-react Context

interface Web3ReactContextInterface<T = any> {
  activate: (
    connector: AbstractConnectorInterface,
    onError?: (error: Error) => void,
    throwErrors?: boolean
  ) => Promise<void>
  setError: (error: Error) => void
  deactivate: () => void

  connector?: AbstractConnectorInterface
  library?: T
  chainId?: number
  account?: null | string

  active: boolean
  error?: Error
}

web3-react@core API Reference

Web3ReactProvider

web3-react relies on the existence of a Web3ReactProvider at the root of your dApp (or the subtree which you'd like to have web3 functionality).

Props

getLibrary: (provider: any) => any

Example

import { Web3ReactProvider } from '@web3-react/core'
// ...

function getLibrary(provider) {
  return new Web3Provider(provider) // this will vary acccording to the web3 convenience library you use
}

function App () {
  return (
    <Web3ReactProvider getLibrary={getLibrary}>
      {/* <...> */}
    </Web3ReactProvider>
  )
}

createWeb3ReactRoot

In some cases, a dApp may want to maintain >1 active web3 connections simultaneously. This could be for any number of reasons, including:

• Wanting "always-on" access to a remote node, while letting users bring their own accounts as necessary
• Communicating with a sidechain and mainnet in tandem
• Balancing an in-browser burner wallet with other connection methods

In cases like these, you'll likely want to create a second (or maybe even third third, but probably not fourth) root, which will function exactly like another Web3ReactProvider (in fact, Web3ReactProvider uses createWeb3ReactRoot under the hood).

Arguments

key: string

Example

import { Web3ReactProvider, createWeb3ReactRoot } from '@web3-react/core'
// ...

function getLibrary(provider) {
  return new Web3Provider(provider) // this will vary acccording to the web3 convenience library used
}

const Web3ReactProviderReloaded = createWeb3ReactRoot('anotherOne')

function App () {
  return (
    <Web3ReactProvider getLibrary={getLibrary}>
      <Web3ReactProviderReloaded getLibrary={getLibrary}>
        {/* <...> */}
      </Web3ReactProviderReloaded>
    </Web3ReactProvider>
  )
}

useWeb3React

If you're using Hooks (😇), useWeb3React is your best friend. Call it from within any function component to access the web3-react Context. Just like that.

Arguments

key?: string

Example

import { useWeb3React } from '@web3-react/core'

function Component () {
  const web3React = useWeb3React()
  // ...
}

getWeb3ReactContext

If you're not using Hooks (😳), getWeb3ReactContext is your savior. It will give you direct access to the context returned by createContext, which will unlock the use of contextType in class components, the Context.Consumer pattern, or whatever other render prop/HOC/etc. shenanigans your manager whose personal site still runs on PHP is making you write.

Arguments

key?: string

Example

import { getWeb3ReactContext } from '@web3-react/core'

const web3ReactContext = getWeb3ReactContext()

UnsupportedChainIdError

This is an error which can be used to inform users that they're connected to an unsupported network.

Example

import { UnsupportedChainIdError } from '@web3-react/core'
// ...

function Component () {
  const { error } = useWeb3React()
  const isUnsupportedChainIdError = error instanceof UnsupportedChainIdError
  // ...
}