Spend more time building for your users, less on wallet integration

Integration of ic-reactor with IdentityKit

Background

Currently, integrating ic-reactor with IdentityKit requires wrapping the entire application in multiple providers and manually updating the agent and authentication state. This approach is less straightforward and user-friendly compared to modern Ethereum development tools like Wagmi.

Ethereum Approach and Developer Experience

In the Ethereum ecosystem, libraries like Wagmi have significantly improved the developer experience. Wagmi provides a set of React hooks for Ethereum, while Viem handles the lower-level interactions with the Ethereum network.

Key aspects of the Wagmi approach:

  1. Configuration-based setup
  2. Seamless integration of wallet connections
  3. Automatic handling of network changes and disconnects
  4. Easy-to-use hooks for common operations

For example, in a Wagmi setup:

import { createClient, http } from "viem"
import { sepolia } from "viem/chains"
import { createConfig } from "wagmi"
import { injected, coinbaseWallet, walletConnect } from "wagmi/connectors"

export const walletConnectConnector = walletConnect()
export const coinbaseWalletConnector = coinbaseWallet()
export const config = createConfig({
  chains: [sepolia],
  connectors: [walletConnectConnector, coinbaseWalletConnector, injected()],
  client({ chain }) {
    return createClient({ chain, transport: http() })
  }
})

function App() {
  return (
    <WagmiProvider config={config}>
      <YourApp />
    </WagmiProvider>
  )
}

and they will have:

This approach allows developers to easily configure their dApp and start using Wagmi’s hooks without worrying about the underlying complexity.

Proposed Approach for ic-reactor and IdentityKit

We should consider adopting a similar approach for ic-reactor and IdentityKit integration. This would involve:

  1. Creating a configuration object that combines ic-reactor and IdentityKit settings
  2. Developing a single provider component that handles both ic-reactor and IdentityKit functionalities
  3. Providing hooks that abstract away the complexity of agent management and identity handling

Here’s a proposed implementation:

import { createAgentConfig, AgentProvider } from '@ic-reactor/react'
import { NFIDW, Plug, InternetIdentity } from "@nfid/identitykit"

const config = createAgentConfig({
  signers: [NFIDW, Plug, InternetIdentity],
  featuredSigner: NFIDW,
  targetCanisters: ["canister-id"],
  authType: 'delegation',
  onConnectSuccess: () => console.log('Connected successfully'),
  onConnectFailure: (e) => console.error('Connection failed:', e.message),
})

function App() {
  return (
    <AgentProvider config={config}>
      <ActorProvider canisterId="YourCanisterId">
        <YourApp />
      </ActorProvider>
    </AgentProvider>
  )
}

In this setup, developers would use hooks provided by ic-reactor:

import { useQueryCall, useAuth } from '@ic-reactor/react'

function YourComponent() {
  const { isConnected, connect, disconnect } = useAuth()
  const { data, loading } = useQueryCall({
     functionName: "YourFunctionName"
  })

  // Use these hooks to interact with the IC network and manage identity
}

Benefits

  1. Simplified setup process
  2. Improved developer experience
  3. Consistency with modern web3 development practices
  4. Easier adoption for developers familiar with Ethereum tools

Next Steps

  1. Gather feedback from the community on this approach
  2. Design and implement the configuration system
  3. Develop the integrated provider component
  4. Create and document new hooks for common operations
  5. Update documentation and provide migration guides

Community Input

We’d like to hear from the community:

  1. How does this approach align with your development needs?
  2. Are there specific features from Ethereum tools you’d like to see implemented?
  3. What challenges do you foresee in adopting this new approach?

Please share your thoughts and feedback to help shape the future of IC development tools.

5 Likes