DTeam 技术日志

Doer、Delivery、Dream

面向 dapp 开发者的前端工程实践

胡键 Posted at — Nov 13, 2020 阅读

老实讲,促使本文写作的动机有三点:

由于我目前的空闲时间有限,也就以条目的形式随意写一点东西吧。

语言和框架

按理说,这部分内容完全是多余,但其实不是。

在我的印象里,国内前端开发应该基本上被三大框架瓜分得差不多,但怪事恰恰被我遇上:某 dapp 项目在我介入的时候,居然发现了久违的 jQuery ,而且完全没有任何前端工程而言:一个 html 文件 + 一堆 js 文件。

这里首先声明,我已不是当年的我,现在早已对各类工具无感,只要能办成事,挣到钱,其实无所谓。因此 jQuery 并不在我歧视之列,并且自己写的 vscode-page 其实也用了历史悠久的模板库:handlebars.js

上面那个 jQuery 工程的问题在于:代码杂乱无章,到处可见复制黏贴的痕迹,即便放在 10+ 年前,该工程也不能说得上好。因此,除非你对自己的代码掌控力十分自信且得到大家认可,还是俗套一点:选择一个前端框架,这样起码会有一个不错的起点。

至于语言,有条件的话还是采用 TypeScript,单单类型检查就能让你避免很多潜在问题。此外,也别忘了一些配套设施:自动化的代码风格检查、vscode 插件等等。这里摘抄一下以前文章的内容

工程相关

因为本质上 vscode 插件开发是前端工程的范畴,并且我们团队主要采用 TypeScript ,因此用到的插件和规范如下:

代码风格:

风格可商量余地:

  • “strict”: true + “no-any”: false,允许

相关插件:

  • ESLint
  • Bracket Pair Colorizer 2
  • Prettier
  • markdownlint
  • indent-rainbow
  • Path Intellisense
  • Peacock

最后,补充一个极大提高效率的 vscode 插件:tabnine,谁用谁知道。

数据精度

数据精度问题让我丢了大人,至今觉得过意不去。但是,这类问题在做后端时候从未出现,现在想来,有几个原因:

结果待到上线日,出现了状况。

由于 dapp 项目对于数字很敏感,稍有差池就会出现问题,因此作为 dapp 开发者需要对数据精度保持高度重视。这里列出几个我觉得比较重要的地方:

合约交互

本来,我觉得像 ethers.js 这么好用的库没有理由不被很多人知道。结果恰恰相反,实在让人大跌眼镜!

除非你有非常特异的需求,并且不仅限于跟合约交互,比如还想去试试发消息和存储,我建议直接使用 ethers.js,不要用 web3.js。原因很简单:

假如你还想增强合约方法(比如你想一次性完成:先预估 gas,然后设置 gaslimit ,然后执行合约方法)也很方便。

状态管理

页面状态很关键,对于 dapp 更是如此。因为这里至少有两个地方需要注意:

以 uniswap 兑换为例:

所有这些状态应该在前端各个页面流畅地体现出来,即这里牵涉到状态传递地问题。如果不使用状态管理工具库的话,其实很容易写出很繁杂地代码。

可能有人说,这个简单,一个全局对象就行了:一个全局的 json 对象。不错,单从静态最终结果而言,全局对象是数据共享的最简单方法。但是,如何应对数据的变化呢?即,数据变化后能方便地通知出去。你可能会说,这个也很简单,封装成一个 Observable 然后让需要页面订阅就行了。不错哟,连 Observable 都知道。

但,即便如此,我还是希望劝你不要自己干这个事情,因为很快就会又有新的需求出现,而这些已经在那些成熟的状态管理库里实现好了。

这里,我推荐 Akita,简单、轻量、好用,相比 redux 和 ngrx 而言。

至于如何接收链上通知,你可以去看看 ethers.js 的文档,其中有相关的介绍。我建议的最简使用方式,直接监听 block mined 事件,然后去获取你需要的内容。

Web3 和 Metamask

Metamask 在做些 breaking change 的事情,涉及到 API 的变化,比如不再注入 web3 ,取而代之的是 window.ethereum 。如果你还抄的是网上那些老代码,最好赶紧检查一下尽快替换。

关于 api 的情况,请检查其开发文档

部署

最后,说一说部署方式,这一点我原本以为也是常识性内容。

dapp 基本上就是一个静态站点,部署其实很简单,直接一个 web server 就行了。在当今处处大吹特吹“云原生”的时代,我们是不是也应该蹭蹭热点呢?!

停止自己买机器,然后搭 web server,再上传文件的做法!这里,我也发现不少人也没搞清楚前端构建是怎么回事。还以为放进去的代码可以很容易让人看出来咋回事。这完全是 10+ 年前的思维!

就当下而言,主流前端框架基本都至少具备了打包、压缩和混淆的功能,最后的代码基本没法看。因此,这种担心基本是多余的。

就部署方式而言,当前简单、省钱且更优的做法就是选用云服务商的:oss + cdn 架构。比起自建服务器而言,效果完全不是一个档次。

好了,这次就说这么多吧,等有时间再细聊。


广告时间

或许你对以下的付费内容感兴趣 …… 😄


相关文章