说来惭愧，从事前端开发多年，也开源过不少项目，然而却从未做过测试工作。内心抵触的原因大概是：

• 我的代码不需要测试！（手动狗头
• 测试用例写起来太麻烦了
• 没想清楚前端的测试用例到底该测啥
• 不清楚组件测试该怎么做（技术栈太复杂）

全文见此：https://zhuanlan.zhihu.com/p/352143497

高阶组件的 Props 代理有一些很常见的场景：

• Props 比原组件多了一些属性
• Props 比原组件少了一些属性
• 给原组件的 Props 的某些属性设置了默认值

那么在下面这个操作之前：

1

<RawComponent {...props} />

你是否会先对 props 做一些「编辑」操作呢？比如删除某些属性，赋值某些属性。

引言

底层实现有时候不必循规蹈矩，能解放业务层才是关键。如果底层为了守规矩反而破坏了业务层的规矩才是得不偿失的添乱行为，行话叫过度设计。
其实这也是所谓封装的原则之一，从函数到模块到组件到页面再到工程的设计都应当秉持着为更上一层服务的原则，尽可能地把下一层的脏话累活揽到自己的作用域下，屏蔽到角落里。
说到这，突然想到一个词：金玉其外 败絮其中……

最近在搞一个基于 AntPro 的管理端。除了把诸如多语言、动态主题配置、各种无用的依赖、文件、页面、配置等等都干掉了之后，我不禁盯着项目里的 dva 又陷入了沉思…

3 秒后，我决定也把它送到非洲去…

于是又是一顿猛如虎的操作（删配置，删依赖，删 models，删 connect，删 props 引用）后，看着清清爽爽的工程结构，我笑了。

🌈 如果你受够了 AntDesign 的原生 Form，那就来试试它吧！一款更懂你的表单提交组件。 项目地址

双向绑定？虚拟 DOM？ - 知乎提问

一直觉得这两个框架的根本区别是 api 设计的理念。

vue 更倾向于某件事情大部分场景下都是需要重复做的，ok，我来帮你做，你只需要做剩余的部分；react 更倾向于给你提供最基础的功能，重复的事情你自己来组合吧。

例子：

最近工作的前端框架从 Vue 转移到了 React，业务组件从 element 转移到了 ant-design。

没错，又是喜闻乐见的后台管理项目，技术栈变了，可造轮子的心没变，先从实现一个 Modifier 组件开始吧。