接上篇，在 Vue 中你可以 这样 a.b.c.d 进行 watch，在 lodash 你也可以以同样的形式进行属性的读取，思索其中中源码实现才有了这篇文章
_.get 基本语法

1
2
3
4
5
6
7

// 基本语法
_.get(obj, path, "defaultValue");

_.get(obj, "a.b[0].c", "defaultValue");

// 或者 path 以数组的形式
_.get(obj, ["a", "b", "0", "c"], "defaultValue");

path 支持两种形式的传值，数组和字符串，我们需要转成统一的数组形式，便于取值

今天刷推特的时候看到 TC39 的成员说 js 的两个语法糖提案进入 stage 4，最终板上钉钉，修成正果。

• Optional Chaining
• Nullish Coalescing
  其中 Optional Chaining 在这之前的 TS 3.7 中就被引入了

Optional Chaining

在此之前使用我们通常获取一个多层级对象一个比较内层的属性，为了避免为空的情况不得不这样写

1

let prop = a.b && a.b.c && a.b.c.d // 取到值或者赋值为 undefined

习惯了 Lodash 之后

1

let prop = _.get(a, "b.c.d", undefined) // 可以自定义默认值

使用 Optional Chaining 之后

1

let prop = a?.b?.c?.d

首先，假定你对函数式编程有所涉猎。用不了多久你就能明白纯函数的概念。随着深入了解，你会发现函数式程序员似乎对纯函数很着迷。他们说：“纯函数让你推敲代码”，“纯函数不太可能引发一场热核战争”，“纯函数提供了引用透明性”。诸如此类。他们说的并没有错，纯函数是个好东西。但是存在一个问题……

纯函数是没有副作用的函数。^[1] 但如果你了解编程，你就会知道副作用是关键。如果无法读取 𝜋 值，为什么要在那么多地方计算它？为了把值打印出来，我们需要写入 console 语句，发送到 printer，或其他可以被读取到的地方。如果数据库不能输入任何数据，那么它又有什么用呢？我们需要从输入设备读取数据，通过网络请求信息。这其中任何一件事都不可能没有副作用。然而，函数式编程是建立在纯函数之上的。那么函数式程序员是如何完成任务的呢？

简单来说就是，做数学家做的事情：欺骗

前言

一直觉得装饰器的写法有种蜜汁好感和好奇，例如 @component或者@connect(x, y)。

装饰器在 React 和 Angular 中很常见，因为这两个框架很强调类，而装饰器的作用范围正是类和类成员，来看装饰器提案的一句话

Decorators make it possible to annotate and modify classes and properties at design time.

指出了装饰器作用对象，注意到最后三个单词 at design time, 再抄袭一句话

装饰器对类的行为的改变，是代码编译时发生的，而不是在运行时。这意味着，装饰器能在编译阶段运行代码。也就是说，装饰器本质就是编译时执行的函数

多年来，我注意到自己在处理组件 api 和构建应用程序和库方面有一系列模式。以下是一系列如何设计组件 api 的想法、观点和建议，这会让组件更灵活、更具有组合性、更容易理解。这些规则都不是硬性的，但它们帮助我想明白了如何组织和创建组件。

提供最少的 API

正如 React 库本身的目标是 最少化 API 一样，我建议在设计组件 API 时采用类似的观点。需要学习的新内容越少，其他人就越容易知道如何使用你创建的组件，从而使它们更可容易被重用。如果有人不理解你的组件 API，那么他们重复你的工作的可能性就会增加。这是我如何创建组件的核心理念，我发现在我工作中牢记它很有帮助。

高阶函数

• map
• filter
• some
• every
• reduce
• unary
• once
• pluck
• pick
• zip
• flatten
• merge
• takeLast
• uniq
• omit
• memoized
• compose
• pipe
• debounce
• throttle