原本以为两篇文章的内容应该足以覆盖 Ethers.js 的关键内容,但目前看来似乎还有些遗漏,于是乎就有了这个续篇。与之前的风格一样,本篇的内容同样采用问题驱动的风格。
在本篇中,你可以了解到:
相比前两篇包含的都是实战代码,本篇则更偏向于开发策略和一些优化方法的总结。
从接触 dapp 开发的第一天,你就要跟地址打交道,不论是 EOA 还是 contract address,离了任何一个都很难开发出有意义的应用。地址本身,其实没有什么太多的复杂性,即便你不了解以下的几个事实,也并不影响应用的开发:
ethers.utils.computeAddress
ethers.utils.getContractAddress
然而,一个容易忽略的细小地方却可能对于你的 dapp 体验带来比较大的影响,虽然这个影响在数据量小的时候并不会暴露出来:地址同时包含了大小写。
这种地址有个专有名称:Checksum 地址
,并且 ethers 也提供了方法来得到它:ethers.utils.getAddress
。对于一般 dapp 来说,如何生成和计算 checksum 地址并不重要,真正值得关注的地方在于:你打算如何保存地址?
我在这篇状态同步的文章里曾经解释过为何要做状态同步的同步的原因,也提到过一般会利用数据库来作为状态同步数据的存储。看到这里,有经验的朋友应该很快就会明白我的潜台词:地址的大小写会影响数据查询的速度!
没错,这正是我的意思。看看典型的一个开发场景:findSomethingByAddress
。它的几个版本的演进可能是这样的:
select * from some_table where address = $1
select * from some_table where address ilike $1
当然,也可以利用字符串函数把大小写统一转换再用相等比较来实现,但是 ilike
最省事嘛,😄。
然而,问题似乎并没有解决。
原因很简单:ilike
不会命中索引。并且,如果即使前面用了函数加相等判断来解决,也会有同样的问题,或许熟悉数据库(如 PG)的同学会说:利用表达式索引就行了。
本文是付费文章,剩余内容请访问以下链接支付之后继续阅读:
付费链接 (已付费:10)