IFABLE

如果你问一个 React 面试题：”setState 之后发生了什么？”，标准答案应该是——React 创建 update 对象、调度更新、经过 reconciler 的 diff 过程、最后 commit 到 DOM。但如果追问：”reconciler 是怎么遍历 Fiber 树的？diff 算法的 O(n) 是怎么做到的？”，能回答清楚的人就少很多了。

这篇文章从 React 源码的调用链路出发，追溯从 ReactDOM.render 到真实 DOM 更新的完整过程。重点放在两个核心机制上：Fiber 架构为什么要替代 Stack Reconciler，以及 diff 算法做了哪些假设把复杂度从 O(n³) 降到 O(n)。

HOC、Hooks、异步组件、React 18——这四个话题放在一起，因为它们代表了 React 在不同阶段对”组件逻辑复用”这个问题的答案。

高阶组件（HOC）是 Class 组件时代的解决方案。Hooks 出现后，大部分 HOC 的场景被取代了，但 HOC 的设计思想——组合优于继承——仍然是理解 React 的关键。异步组件解决的是代码体积问题，React 18 的 Concurrent Mode 则是在渲染模型层面动了刀。

React 入门：从 MV* 到组件化

React 是一个声明式的 JavaScript 库，用于构建用户界面。它的核心公式很简单：UI = render(data)——数据单向流动，你描述 UI 应该长什么样，React 负责把它渲染出来。

但在理解 React 之前，有必要先搞清楚它试图解决什么问题。我们来从 MVC 和 MVVM 这两种经典模式说起。

你一定用过”微信登录”或”Google 登录”。点一下按钮，第三方应用就拿到了你的头像和昵称——但你从来没有把微信密码告诉过它。这是怎么做到的？

答案就是 OAuth 2.0。它不是什么新东西，2012 年就发布了 RFC 6749，但直到今天仍然是互联网授权的事实标准。

本文转载自龙爪槐守望者的微博

软/硬件特性

首屏

根据用户手机分辨率，考虑哪些信息必须首屏展示

系统和平台差异

注意系统差异，例如 Android picker 风格、返回机制、手势等
考虑小程序某些效果是否能实现

新老版本共存

新增功能时，对老版本的影响

本文为「TypeScript 深入理解」系列第 4 篇，也是最后一篇。我们将前面三篇的类型知识落地到实际场景：类型断言、type vs interface 选型，以及一个完整的 axios 封装案例。

本文为「TypeScript 深入理解」系列第 3 篇，涵盖五种装饰器和 tsc 编译器的五步管线。前两篇分别介绍了类型系统基础和面向对象/泛型。

本文为「TypeScript 深入理解」系列第 2 篇，涵盖类、泛型、枚举、迭代器、继承、多态和抽象类。第 1 篇介绍了基础类型系统和函数签名。

本文为「TypeScript 深入理解」系列第 1 篇，后续文章将分别覆盖面向对象与泛型、装饰器与编译原理、实战技巧与模式。

在一次业务实践中需要在 MongoDB 中使用自增 ID，而 MongoDB 本身并不支持自增 ID。我们需要通过一个单独的集合保存 ID，使用 FindOneAndUpdate 和 $inc 操作符实现 ID 的自增.
然而此时需要操作两个集合，因 MongoDB 的原子性只是针对单文档的，故会出现 ID 增加而插入失败的情况。
好在 MongoDB 在 4.0 中，支持了副本集上的多文档事务，在版本 4.2 中，引入了分布式事务，这增加了对分片群集上的多文档事务的支持，并合并了对副本集上多文档事务的现有支持。

MongoDB事务

事务介绍

在 MongoDB 中，对单个文档的操作是原子的。由于您可以使用嵌入的文档和数组来捕获单个文档结构中的数据之间的关系，而不是跨多个文档和集合进行规范化，因此这种单一文档的原子性消除了对多文档的需求许多实际用例的事务。
对于需要对多个文档（在单个或多个集合中）进行读取和写入原子化的情况，MongoDB 支持多文档事务。对于分布式事务，事务可用于多个操作、集合、数据库、文档和分片。