TypeScript 装饰器与编译原理——元编程与编译管线
本文为「TypeScript 深入理解」系列第 3 篇,涵盖五种装饰器和
tsc编译器的五步管线。前两篇分别介绍了类型系统基础和面向对象/泛型。
本文为「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 支持多文档事务。对于分布式事务,事务可用于多个操作、集合、数据库、文档和分片。
一个 React 后台管理系统堆了两百多个页面,每次 CI 跑 45 分钟。产品经理想把隔壁团队用 Vue 写的客服系统嵌进来——“用户不要两个入口,要一个。”
这就是微前端要解决的问题。不是”多个团队怎么协作”这种管理学命题,而是你真实会遇到的:构建太慢、技术栈不统一、不同团队互相阻塞发布。
在移动端,各个平台或UI系统的原始指针事件模型基本都是一致,即:一次完整的事件分为三个阶段:手指按下、手指移动、和手指抬起,而更高级别的手势(如点击、双击、拖动等)都是基于这些原始事件的。
当指针按下时,Flutter会对应用程序执行命中测试(Hit Test),以确定指针与屏幕接触的位置存在哪些widget, 指针按下事件(以及该指针的后续事件)然后被分发到由命中测试发现的最内部的widget,然后从那里开始,事件会在widget树中向上冒泡,这些事件会从最内部的widget被分发到widget根的路径上的所有Widget,这和Web开发中浏览器的事件冒泡机制相似, 但是Flutter中没有机制取消或停止冒泡过程,而浏览器的冒泡是可以停止的。
Flutter中可以使用Listener widget来监听原始触摸事件,它也是一个功能性widget。
初步了解 Flutter 应用可以通过分析 Android Studio 创建的 Flutter 应用模板来了解。
打开 Android Studio,创建一个 Flutter 工程应用 flutter_app。Flutter 会根据自带的应用模板,自动生成一个简单的计数器示例应用 Demo。
该工程的代码如下: