Banner 图来自 ant.design

聊到封装，其实无论是组件还是函数，还是模块，都应当遵循单一职责这个大原则，行话叫高内聚，低耦合。

前言

本文基本上囊括了非端侧小程序引擎实现的方方面面，其中还涵盖了大量的微信小程序开发文档里不会告诉你的特性细节（可作为引擎侧的测试用例）。理论上本文可以作为实现小程序引擎的技术细节文档来查阅，不太适合通读。

详情

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

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

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

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

1

<RawComponent {...props} />

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

简单来说，它就是用来滚动切换列表项的。 项目地址

引言

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

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

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

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

一组简单实用的语义化 flex 样式类，通过它们基本可以组合出所有常见的业务布局。 项目地址

代码提示

目前用的是：Wechat mini program support

实测提示效果还不错。

Prettier

直接调用 WebStorm 自带的 Prettier 去格式化 wxml / wxss / wxs 文件会提示：

就拿 axios 请求后台 api 来说吧 很多人喜欢把 api 专门写到一个文件里 然后每个页面里面请求的时候 import 导入。
这样确实可以统一管理 api 接口。但是用多了反而感觉很麻烦。一个 import 导入的时候麻烦。第二个是后期维护修改的时候并没有感觉到便利。 反而这个文件跳那个文件 那个再跳另一个。总感觉切换查看不同文件是一个很浪费时间的过程。当然坏处就是不能复用，真的用的很多的接口也提出来 - 知乎提问

先回答问题本身：当然有必要。

1
2
3
4
5
6
7
8
9

function test() {
  return new Promise((resolve) => {
    throw Error('callback error')
  })
}

test()
  .then()
  .catch(() => console.log('catch!'))

其实原本我以为回调中的异常可能得这样捕获：

1
2
3
4
5

try {
  test()
} catch (e) {
  // catch!
}

想多了。。