Web3 SDK import about ant-design-web3

[kiner-tang]

看起来是第二套方案更契合

具体怎么设计有没有什么想法？

如果要成为统一解决方案应该还是要兼容各种链，我们可以默认支持以太坊及其兼容链，其他链提供统一接入的 SDK ，让社区开发者维护

我也更赞成这个方案，官方支持一个主流的，其他的我们抽象好让用户自己扩展，社区维护。

[yutingzhao1991]

具体的实现方式可以讨论下，我的想法是我们可以设计一系列的 Common API，这个 API 是提供给 antd web3 用的，比如：

• getAccounts
• queryNFTMetas
• disconnect

这一套 API 是和链不直接相关的，对于使用 antd web3 的用户来说不需要关心，主要是为了兼容不同的链，具体的用法如下：

import { ChainProvider, ConnectButton } from '@ant-design/web3';
import ProviderAdapter from 'antd-web3-adapter-ethers';
import * as ethers from 'ethers';

export default function() {
  return (
    <ChainProvider provider={new ProviderAdapter(ethers)}>
      <ConnectButton />
    </ChainProvider>
  );
}

通过实现类似 antd-web3-adapter-ethers 的包来兼容不同的链和 SDK，这个包封装各个链的 sdk 提供统一的方法给到 antd-web3。

不过这一系列的 Common API 的设计就比较考究了，如果实现的好也可以直接暴露出来给用户使用，也可以是一套 hooks 也行。

[yutingzhao1991]

方案一：深度封装一套 API，外部完全不需要关注我们使用的是什么 sdk。
方案二：提供一套方案可以适配不同的 sdk，导出对应 sdk 的提供给开发者。
方案三：组件只提供 UI，不集成 sdk。

大家看看有没有什么想法。

[RedJue]

看起来是第二套方案更契合

[kiner-tang]

如果集成 SDK 的话，要是以后有各种平台，会不会维护不过来。

[yutingzhao1991]

如果集成 SDK 的话，要是以后有各种平台，会不会维护不过来。

你说的各种平台是指各种链吗？

这也是一个问题，我们是只支持兼容以太坊的链还是要提供各种链的适配方案？

另外维护的话如果要支持多平台那肯定要设计一套方案可以让社区去配置维护，就不能内置在我们组件里面了，做成插件包。

[yutingzhao1991]

看起来是第二套方案更契合

具体怎么设计有没有什么想法？

[RedJue]

看起来是第二套方案更契合

具体怎么设计有没有什么想法？

如果要成为统一解决方案应该还是要兼容各种链，我们可以默认支持以太坊及其兼容链，其他链提供统一接入的 SDK ，让社区开发者维护

[RedJue]

具体的实现方式可以讨论下，我的想法是我们可以设计一系列的 Common API，这个 API 是提供给 antd web3 用的，比如：

• getAccounts
• queryNFTMetas
• disconnect

这一套 API 是和链不直接相关的，对于使用 antd web3 的用户来说不需要关心，主要是为了兼容不同的链，具体的用法如下：

import { ChainProvider, ConnectButton } from '@ant-design/web3';
import ProviderAdapter from 'antd-web3-adapter-ethers';
import * as ethers from 'ethers';

export default function() {
  return (
    <ChainProvider provider={new ProviderAdapter(ethers)}>
      <ConnectButton />
    </ChainProvider>
  );
}

通过实现类似 antd-web3-adapter-ethers 的包来兼容不同的链和 SDK，这个包封装各个链的 sdk 提供统一的方法给到 antd-web3。

不过这一系列的 Common API 的设计就比较考究了，如果实现的好也可以直接暴露出来给用户使用，也可以是一套 hooks 也行。

赞成，和我预期的基本一致。

[yutingzhao1991]

最近在做的时候有了不一样的想法：

import { ConnectButton, Web3ProviderInterface, useNFTMetadata, NFTCard } from '@ant-design/web3';
import {
  createProvider,
  EIP1193LikeProvider,
  chains,
  Web3Provider,
  WalletConnectProivder,
  MetaMaskProvider,
  ZANJSONRpcProvider
} from '@ant-design/web3-ethereum';

const provider: EIP1193LikeProvider = createProvider({
  // 这里可以提供一些预设
  rpcs: [new ZANJSONRpcProvider({})],
  wallets: [
    new WalletConnectProivder({
      projectId: 'xxx'.
    }),
    new MetaMaskProvider({}),
  ],
  chains: [chains.mainnet],
});

export default () => {
  const { metadata } = useNFTMetadata({});
  return (
    <Web3Provider provider={provider}>
      <ConnectButton />
    <Web3Provider/>
  );
}

和现在的差异是：

• 取消 adapter 的概念，不需要适配各种 sdk，而是 @ant-design/web3-ethereum 提供符合 EIP1193 的 provider 给 SDK 集成
• 组件最外层的配置 Provider 由 @ant-design/web3-ethereum 包提供，它需要实现 Web3ProviderInterface 相关接口。其实类似现在的 adapter 的包，只不过不再针对不同的 sdk 适配。内部可以通过直接调用符合 EIP1193 标准的 provider 的 request 方法来实现，部分涉及到合约序列化和反序列化的部分可能要借助现在的一些 sdk 的实现，但是用户无感。
• 组件基于 Web3ProviderInterface 来和链交互，理论上可以支持非 EVM 的链，比如未来提供一个 @ant-design/web3-sui 这样的包用来支持 SUI 这条链。
• 类似 WalletConnectProivder 这样的通用的内容放到 @ant-design/web3-common 中，由 @ant-design/web3-ethereum 导出，未来也可能由 @ant-design/web3-sui 导出。

[jeasonstudio]

• EIP1193 API 还是比较底层的，对开发者这样暴露感觉是 OK 的，但我们内部实现的时候可能还是要基于比如 ethers/web3/wamgi 这样的库会更健壮
• 非 eth rpc 的链感觉会更复杂一些，甚至组件交互上都会跟 evm 链有区别