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:
- Configuration-based setup
- Seamless integration of wallet connections
- Automatic handling of network changes and disconnects
- 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:
- Creating a configuration object that combines ic-reactor and IdentityKit settings
- Developing a single provider component that handles both ic-reactor and IdentityKit functionalities
- 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
- Simplified setup process
- Improved developer experience
- Consistency with modern web3 development practices
- Easier adoption for developers familiar with Ethereum tools
Next Steps
- Gather feedback from the community on this approach
- Design and implement the configuration system
- Develop the integrated provider component
- Create and document new hooks for common operations
- Update documentation and provide migration guides
Community Input
We’d like to hear from the community:
- How does this approach align with your development needs?
- Are there specific features from Ethereum tools you’d like to see implemented?
- 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.