看的见的思考
reactive
test('Object', () => {
const original = { foo: 1 }
const observed = reactive(original)
expect(observed).not.toBe(original)
expect(isReactive(observed)).toBe(true)
expect(isReactive(original)).toBe(false)
// get
expect(observed.foo).toBe(1)
// has
expect('foo' in observed).toBe(true)
// ownKeys
expect(Object.keys(observed)).toEqual(['foo'])
})
从这个单元测试的 demo 开始
export function reactive<T extends object>(target: T): UnwrapNestedRefs<T>
export function reactive(target: object) {
// if trying to observe a readonly proxy, return the readonly version.
if (target && (target as Target)[ReactiveFlags.IS_READONLY]) {
return target
}
return createReactiveObject(
target,
false,
mutableHandlers,
mutableCollectionHandlers,
reactiveMap
)
}先从 createReactiveObject 开始
这里别的什么都不需要管，先看看他做了什么事
不需要关心 mutableHandlers、mutableCollectionHandlers、reactiveMap 都做了什么
在 createReactiveObject 里面最核心的逻辑是
function createReactiveObject(target){
const proxy = new Proxy(
target,
targetType === TargetType.COLLECTION ? collectionHandlers : baseHandlers
)
return proxy
} 最核心的逻辑其实就是用 Proxy 给包裹一下，然后这里是需要基于一个 targetType 的类型去选择用不同的 handlers 的
那我们看看 targetType 都有哪几种？
看 getTargetType
return value[ReactiveFlags.SKIP] || !Object.isExtensible(value)
? TargetType.INVALID
: targetTypeMap(toRawType(value))无效的和正常了 type 做了区分
无效的情况是：
有 ReactiveFlags.SKIP 字段 或者 对象是不可以扩展的
那在什么情况下需要对象用到扩展呢？
剩下的点都在 targetTypeMap 里面声明好了
function targetTypeMap(rawType: string) {
switch (rawType) {
case 'Object':
case 'Array':
return TargetType.COMMON
case 'Map':
case 'Set':
case 'WeakMap':
case 'WeakSet':
return TargetType.COLLECTION
default:
return TargetType.INVALID
}
}所以总结一下就是：
-
TargetType.COMMON:
-
TargetType.COLLECTION
-
TargetType.INVALID
好 ，类型知道了，那我们的参数是一个对象 {foo:xxx} 所以看看 handlers 应该是 baseHandlers
那么 handlers 就是
TargetType.COMMON → baseHandlers → mutableHandlers
TargetType.COLLECTION → collectionHandlers → mutableCollectionHandlers
mutableHandlers
先看这个方法
export const mutableHandlers: ProxyHandler<object> = {
get,
set,
deleteProperty,
has,
ownKeys
}这里把所有的处理都封装到了具体的函数内了，这次在看要比之前好很多
接着看看 get
get
get 就是调用了 createGetter
function createGetter(isReadonly = false, shallow = false) {
return function get (target: Target, key: string | symbol, receiver: object)=>{
const res = Reflect.get(target, key, receiver)
if (!isReadonly) {
track(target, TrackOpTypes.GET, key)
}
if (isObject(res)) {
// Convert returned value into a proxy as well. we do the isObject check
// here to avoid invalid value warning. Also need to lazy access readonly
// and reactive here to avoid circular dependency.
return isReadonly ? readonly(res) : reactive(res)
}
}
}这里是使用了闭包的概念，让调用者可以少写几个参数，而且从概念上也做了分离，在create 的时候就可以标注是不是 readonly 的 或者是 shallow 的
这里的 get 调用的时机是在触发 proxy.xxx 的 get 操作的时候
而在调用 get 的时候是需要做依赖收集的，而依赖收集的动作就是在 track 里面做的！
而最终的结果就是返回 Reflect.get 的值就可以了
这里有个点，就是如何处理嵌套的 Object， 就是递归的调用 reactive 即可
track 依赖收集
重点：那是如何做依赖收集的呢？？？
export function track(target: object, type: TrackOpTypes, key: unknown) {
let depsMap = targetMap.get(target)
if (!depsMap) {
targetMap.set(target, (depsMap = new Map()))
}
let dep = depsMap.get(key)
if (!dep) {
depsMap.set(key, (dep = new Set()))
}
if (!dep.has(activeEffect)) {
dep.add(activeEffect)
activeEffect.deps.push(dep)
}
}这里的重点就是如何存储 dep
这里有两层关系，
target → depsMap
key → dep
例如：
那 target 就是 user
target 对应的就是 depsMap
age 对应一个 dep
那 activeEffect 是什么呢？其实就是依赖（通过 effect 给到的 function）
effect(()=>{
// 这个 函数就是 activeEffect
})而把 activeEffect 添加到dep里面的操作就是依赖收集
到这里依赖收集的动作就已经都搞定了
那注意这里的 dep 只是一个 set 数据结构
需要看看 activeEffect 是从哪里过来的
这里的 activeEffect 是在 createReactiveEffect 赋值的
function createReactiveEffect<T = any>(
fn: () => T,
options: ReactiveEffectOptions
): ReactiveEffect<T> {
activeEffect = effect
}所以这个 activeEffect 确实是调用 effect 时候的依赖函数
在来分析分析这几个参数
export function track(target: object, type: TrackOpTypes, key: unknown) {target 就是对应的对象
type 的作用是后续给 debug 的时候调用的，方便用户知道当前是什么类型
if (__DEV__ && activeEffect.options.onTrack) {
activeEffect.options.onTrack({
effect: activeEffect,
target,
type,
key
})
}key 是什么？
key 按照以前的理解是 target 对应的 key ，但是下面的 trigger 的时候发现这个key 可能并不只有一种情况，那么我们看看key 都有什么情况把
啊哦，其实大多数情况下都是有key 的，但是有一些特殊的操作是没有key 的，那怎么办？ 自己搞一个被，所以这个就是 ITERATE_KEY 的作用
比如在 ownkeys 的时候，在 size 的时候
function ownKeys(target: object): (string | symbol)[] {
track(target, TrackOpTypes.ITERATE, isArray(target) ? 'length' : ITERATE_KEY)
return Reflect.ownKeys(target)
}
function size(target: IterableCollections, isReadonly = false) {
target = (target as any)[ReactiveFlags.RAW]
!isReadonly && track(toRaw(target), TrackOpTypes.ITERATE, ITERATE_KEY)
return Reflect.get(target, 'size', target)
}Set
function createSetter(shallow = false) {
return function set(
target: object,
key: string | symbol,
value: unknown,
receiver: object
): boolean {
const hadKey =
isArray(target) && isIntegerKey(key)
? Number(key) < target.length
: hasOwn(target, key)
const result = Reflect.set(target, key, value, receiver)
// don't trigger if target is something up in the prototype chain of original
if (target === toRaw(receiver)) {
if (!hadKey) {
trigger(target, TriggerOpTypes.ADD, key, value)
} else if (hasChanged(value, oldValue)) {
trigger(target, TriggerOpTypes.SET, key, value, oldValue)
}
}
return result
}
}这里的核心逻辑是 trigger 也就是触发依赖
但是触发依赖的时候是分情况的，一个是 ADD 一个是 SET
TODO 如何区分触发依赖的时候是 ADD 还是 SET？
先看trigger 的逻辑实现
export function trigger(
target: object,
type: TriggerOpTypes,
key?: unknown,
newValue?: unknown,
oldValue?: unknown,
oldTarget?: Map<unknown, unknown> | Set<unknown>
) {
const effects = new Set<ReactiveEffect>()
……
}先看 Add 的逻辑
switch (type) {
case TriggerOpTypes.ADD:
if (!isArray(target)) {
add(depsMap.get(ITERATE_KEY))
if (isMap(target)) {
add(depsMap.get(MAP_KEY_ITERATE_KEY))
}
} else if (isIntegerKey(key)) {
// new index added to array -> length changes
add(depsMap.get('length'))
}这里是基于不同的类型来从获取 depsMap 里面获取值
那看看 add 干了啥？
const add = (effectsToAdd: Set<ReactiveEffect> | undefined) => {
if (effectsToAdd) {
effectsToAdd.forEach(effect => {
if (effect !== activeEffect || effect.allowRecurse) {
effects.add(effect)
}
})
}
}啊哦， 这里是用 effects 来把 effect 给添加进来的，
那为什么要在这里添加呢？ 不是应该在收集依赖的时候添加吗？ 看看收集依赖做了啥？
track 的时候确实是收集了 effect 里面的依赖函数，没有问题
那看看 effects 后续是用在哪里了吧
// trigger
effects.forEach(run)
在最后一行调用了 effects 执行 run 函数，那这里应该是在 trigger 的时候把之前所有的依赖又重新收集了一遍，那为什么又重新收集了一遍呢？方便后续的统一处理，因为需要在多个地方把所有的 effect 都收集起来
add(depsMap.get(ITERATE_KEY))
这里的 ITERATE_KEY 是什么？ 他是在哪里赋值的？是在什么时候存给 depsMap 的呢？
export const ITERATE_KEY = Symbol(__DEV__ ? 'iterate' : '')
只是一个唯一标识
那看看在哪里存的 ，存的又是什么， 啊哦
在调用 track 的时候会吧这个值给过去，比如：在 ownKeys 的时候 ，那这里需要看看 track 的几个关键的参数
那么如果我们精简一下 set 做的事的话，那么就是：
-
收集所有的 effect （依赖）
-
使用的是 add 函数来添加
-
调用所有的 effect
-
调用的 run 函数来处理
那么继续去看看 run 函数都做了什么吧
const run = (effect: ReactiveEffect) => {
if (effect.options.scheduler) {
effect.options.scheduler(effect)
} else {
effect()
}
}也是非常简单，就是调用一下收集过来的 effect （依赖）
而这里有个特殊处理就是 scheduler 的逻辑实现，这里其实就是调用 scheduler ，让用户自己处理调用的时机（这里先略过）
effect
export function effect<T = any>(
fn: () => T,
options: ReactiveEffectOptions = EMPTY_OBJ
): ReactiveEffect<T> {
const effect = createReactiveEffect(fn, options)
return effect
}fn就是传入的 function ，这里的核心就是创建一个 effect 对象，然后返回即可
接下来看 createReactiveEffect
function createReactiveEffect<T = any>(
fn: () => T,
options: ReactiveEffectOptions
): ReactiveEffect<T> {
const effect = function reactiveEffect(): unknown {
if (!effectStack.includes(effect)) {
cleanup(effect)
try {
enableTracking()
effectStack.push(effect)
activeEffect = effect
return fn()
} finally {
effectStack.pop()
resetTracking()
activeEffect = effectStack[effectStack.length - 1]
}
}
} as ReactiveEffect
effect.id = uid++
effect.allowRecurse = !!options.allowRecurse
effect._isEffect = true
effect.active = true
effect.raw = fn
effect.deps = []
effect.options = options
return effect
}effect 本身就是一个函数，然后给了它很多的属性
没有用对象也没有用 class ， 只是用了 function 来表示的 effect 。这是因为 effect 本身是需要执行的
这里是使用 effectStack 来存储所有的 effect ，以及使用 activeEffect 这个全局的变量来保存当前的 effect 这里的 activeEffect 就和 track 依赖收集关联起来了， 因为 effect 这个函数就是响应式对象的依赖
这里需要探索的是
enableTracking
resetTracking
cleanup
先看 enableTracking
export function enableTracking() {
trackStack.push(shouldTrack)
shouldTrack = true
}咦，这里的 trackStack 又是一个栈，他是做什么的呢？
看看他都是在哪里调用了，trackStack 只是会影响 shouldTrack ，那重点是 shoudlTrack
export function track(target: object, type: TrackOpTypes, key: unknown) {
if (!shouldTrack || activeEffect === undefined) {
return
}最终的使用是会影响到 track 的逻辑
那为什么需要用 stack 来管理一个布尔变量呢？
这里的关键点是 pauseTracking 函数的调用，但是使用它的地方太多了
结合pauseTracking enableTracking resetTracking 来判断的话，应该是需要返回上一个 shouldTrack 的状态
那我们只分析 try 内部的代码的话
try {
enableTracking()
effectStack.push(effect)
activeEffect = effect
return fn()
} finally {
……
}就是先允许 track 然后把 effect 记录到 effectStack 内，接着执行 fn()
而执行 fn 的时候会触发 track 的逻辑，所以正好把当前的 effect 给收集进去了
那我们在看看 finally 的逻辑
try{
……
}finally {
effectStack.pop()
resetTracking()
activeEffect = effectStack[effectStack.length - 1]
}这里的 finally 逻辑是肯定会执行的
所以也就是在收集完依赖后，就需要把之前的 effect 给弹出去了，然后还 resetTracking，但是这里的 resetTracking 是回到上一个状态。 最后把 activeEffect 制成栈顶的值
但是这里是应对什么场景的呢???
可能是嵌套的。TODO
接着看看 cleanup 的逻辑，因为在跟断点的时候发现每次收集到的 dep 都是会被清理的。也就是执行一次，清理一次。
这个逻辑之前大概听尤大讲过，是为了处理一些边缘case ，必须需要每次都清空，我需要找到这个 边缘case 的 demo
function cleanup(effect: ReactiveEffect) {
const { deps } = effect
if (deps.length) {
for (let i = 0; i < deps.length; i++) {
deps[i].delete(effect)
}
deps.length = 0
}
}这里的 deps 是 effect 依赖对应的响应式对象的 dep，之前在 track 的时候 收集进来的。
这里的目的就是把响应式对象里面的依赖都清空。至于为什么，只能是找到对应的 demo 才明白。（应该是为了处理 边缘 case）
看单元测试：
it('should observe multiple properties', () => {
let dummy
const counter = reactive({ num1: 0, num2: 0 })
effect(() => (dummy = counter.num1 + counter.num1 + counter.num2))
expect(dummy).toBe(0)
counter.num1 = counter.num2 = 7
expect(dummy).toBe(21)
})这里本来以为赋值2个key 的话，只会触发一次，但是其实是修改一个key就会触发一次 fn的
it('should observe nested properties', () => {
let dummy
const counter = reactive({ nested: { num: 0 } })
effect(() => (dummy = counter.nested.num))
expect(dummy).toBe(0)
counter.nested.num = 8
expect(dummy).toBe(8)
})如果是个嵌套的对象的话，这里的 counter.nested 的依赖会是 fn，而 counter.nested.num 的依赖也会是 fn
那这个调用的链路都会收集 fn
it('should not be triggered by mutating a property, which is used in an inactive branch', () => {
let dummy
const obj = reactive({ prop: 'value', run: true })
const conditionalSpy = jest.fn(() => {
dummy = obj.run ? obj.prop : 'other'
})
effect(conditionalSpy)
expect(dummy).toBe('value')
expect(conditionalSpy).toHaveBeenCalledTimes(1)
obj.run = false
expect(dummy).toBe('other')
expect(conditionalSpy).toHaveBeenCalledTimes(2)
obj.prop = 'value2'
expect(dummy).toBe('other')
expect(conditionalSpy).toHaveBeenCalledTimes(2)
})看到这个测试的时候，明白了为什么每次都需要 cleanup 了，这里的重点是在 conditionalSpy 内，这里 track 的前提是需要触发 get 之类的操作，而如果说在 effect 的 fn 里面因为有条件逻辑存在的话，就是会有触发不到某个 get 的时候。
比如 conditionalSpy ，在 obj.run 为 true 的时候，这里会触发 obj.run 也会触发 obj.prop。
而 obj.run 变成 false 的时候，这里只会触发 obj.run 。 而只触发 obj.urn 就会意味着 obj.prop 没有收集进来，那当我们去修改了 obj.prop 的值的时候，就不会在执行 effect fn 了。
那如果说我们把代码的执行 path 比作绘画的话，因为这个 path 会改变，所以我们就需要每次都 清空掉，然后重新绘制
哈哈，这里是用游戏逻辑的 reset 来做的比喻
阅读 3.2 版本
变化点在 effect.ts 里面
首先 effect 是用 class 来表示了
export class ReactiveEffect<T = any> {
active = true
deps: Dep[] = []
// can be attached after creation
computed?: boolean
allowRecurse?: boolean
onStop?: () => void
// dev only
onTrack?: (event: DebuggerEvent) => void
// dev only
onTrigger?: (event: DebuggerEvent) => void
constructor(
public fn: () => T,
public scheduler: EffectScheduler | null = null,
scope?: EffectScope | null
) {
recordEffectScope(this, scope)
}
run() {
}
stop() {
}
}只有2个行为，run 和 stop 了
在看 effect 的逻辑
export function effect<T = any>(
fn: () => T,
options?: ReactiveEffectOptions
): ReactiveEffectRunner {
const _effect = new ReactiveEffect(fn)
if (options) {
// 参数的处理
extend(_effect, options)
if (options.scope) recordEffectScope(_effect, options.scope)
}
if (!options || !options.lazy) {
_effect.run()
}
const runner = _effect.run.bind(_effect) as ReactiveEffectRunner
runner.effect = _effect
return runner
}这里的 scope 是做什么用的
执行的时候就是用 _effect.run() 调用即可
这时候的 effect 函数会返回一个新的概念 ReactiveEffectRunner 类型。
那看看这个类型都是做了什么事把
const runner = _effect.run.bind(_effect) as ReactiveEffectRunner
runner.effect = _effect
return runner
这里的 runner 也就是 ReactiveEffectRunner 就是 _effect.run.bind 之后的这个函数
接着看看 effect 里面的 run 都是做了什么
run() {
if (!this.active) {
return this.fn()
}
if (!effectStack.includes(this)) {
try {
effectStack.push((activeEffect = this))
enableTracking()
trackOpBit = 1 << ++effectTrackDepth
if (effectTrackDepth <= maxMarkerBits) {
initDepMarkers(this)
} else {
cleanupEffect(this)
}
return this.fn()
} finally {
if (effectTrackDepth <= maxMarkerBits) {
finalizeDepMarkers(this)
}
trackOpBit = 1 << --effectTrackDepth
resetTracking()
effectStack.pop()
const n = effectStack.length
activeEffect = n > 0 ? effectStack[n - 1] : undefined
}
}
}这里和之前的版本的变化点是控制 track 的布尔值的逻辑变了。别的都是和以前一样的
那重点就看看新增加的逻辑是什么
try {
effectStack.push((activeEffect = this))
enableTracking()
trackOpBit = 1 << ++effectTrackDepth
if (effectTrackDepth <= maxMarkerBits) {
initDepMarkers(this)
} else {
cleanupEffect(this)
}
return this.fn()
} finally {这里的 trackOpBit 和 initDepMarkers 和 cleanupEffect 方法
对比之前的实现的话，每次都是必须会调用 cleanupEffect 来清理依赖的。而现在不是了
先看看 effectTrackDepth
// The number of effects currently being tracked recursively.
let effectTrackDepth = 0
对effectTrackDepth 的赋值是在 try 里面的时候 effectTrackDepth 会执行 ++effectTrackDepth,
而 effectTrackDepth 会影响到initDepMarkers和cleanupEffect 以及finalizeDepMarkers 的执行
这里还有一个关键的控制变量是maxMarkerBits
感觉是个控制值
/**
* The bitwise track markers support at most 30 levels op recursion.
* This value is chosen to enable modern JS engines to use a SMI on all platforms.
* When recursion depth is greater, fall back to using a full cleanup.
*/
const maxMarkerBits = 30
这里的 SMI ，是什么？TODO
目前猜测是基于v8的某些点做的优化策略
目前是
if (effectTrackDepth <= maxMarkerBits) {
initDepMarkers(this)
} else {
cleanupEffect(this)
}那看看小于 maxMarkerBits 的时候的 initDepMarkers 吧
export const initDepMarkers = ({ deps }: ReactiveEffect) => {
if (deps.length) {
for (let i = 0; i < deps.length; i++) {
deps[i].w |= trackOpBit // set was tracked
}
}
}这里也是用了二进制的处理方式来做的标记逻辑。
看看这里的 dep.w 都用在了哪里
以上逻辑的关键点是优化了之前每次都调用 cleanup 的点
export function trackEffects(
dep: Dep,
debuggerEventExtraInfo?: DebuggerEventExtraInfo
) {
let shouldTrack = false
if (effectTrackDepth <= maxMarkerBits) {
if (!newTracked(dep)) {
dep.n |= trackOpBit // set newly tracked
shouldTrack = !wasTracked(dep)
}
} else {
// Full cleanup mode.
shouldTrack = !dep.has(activeEffect!)
}
if (shouldTrack) {
dep.add(activeEffect!)
activeEffect!.deps.push(dep)
if (__DEV__ && activeEffect!.onTrack) {
activeEffect!.onTrack(
Object.assign(
{
effect: activeEffect!
},
debuggerEventExtraInfo
)
)
}
}
}逻辑线索在 shouldTrack ， 都是为了算出是不是需要 track，那么看看有没有 demo 可以验证这个猜测
it('should observe multiple properties', () => {
let dummy
const counter = reactive({ num1: 0, num2: 0 })
effect(() => (dummy = counter.num1 + counter.num1 + counter.num2))
expect(dummy).toBe(0)
counter.num1 = counter.num2 = 7
expect(dummy).toBe(21)
})在这个单测里面证明了上面的猜测，现在我们知道了解决的是什么问题（why）
接着看看是如何做到的 how
如果从优化角度自己思考的话，是希望
-
track 收集依赖只收集一次就好了
-
但是只收集一次的话，code path 变化了要如何解决？
好了，这里使用二进制的原因是因为会有多层级，而用二进制来表示每一个层级的标识
而对于一个 dep 来讲会有2个标识
接着我们看看 dep.n 和 dep.w 都是分别在什么时候被赋值的
stop 的实现
it('stop', () => {
let dummy
const obj = reactive({ prop: 1 })
const runner = effect(() => {
dummy = obj.prop
})
obj.prop = 2
expect(dummy).toBe(2)
stop(runner)
obj.prop = 3
expect(dummy).toBe(2)
// stopped effect should still be manually callable
runner()
expect(dummy).toBe(3)
})看看stop 的功能是如何实现的
这里 stop 是停止侦听，而 runner 是重新run起来
看看stop 都做了什么事
export function stop(runner: ReactiveEffectRunner) {
runner.effect.stop()
}
stop() {
if (this.active) {
cleanupEffect(this)
if (this.onStop) {
this.onStop()
}
this.active = false
}
}function cleanupEffect(effect: ReactiveEffect) {
const { deps } = effect
if (deps.length) {
for (let i = 0; i < deps.length; i++) {
deps[i].delete(effect)
}
deps.length = 0
}
}这里的关键是调用了 cleanupEffect 这个函数，是会把当前的 effect 的 deps 都清空掉
那么也就是说响应式对象里面是没有依赖了，所以当触发 effect 的 trigger 的时候，是没有依赖可以执行的
而再次可以运行的逻辑其实就是重新调用一遍 effect.run
这里的 runner 就是指向的 effect.run 函数
所以后续的操作就是和初始化的逻辑一样了，需要重新的执行 fn ，然后再重新的收集依赖
lazy 的实现
lazy 是为了让用户自己选择调用的时机
it('lazy', () => {
const obj = reactive({ foo: 1 })
let dummy
const runner = effect(() => (dummy = obj.foo), { lazy: true })
expect(dummy).toBe(undefined)
expect(runner()).toBe(1)
expect(dummy).toBe(1)
obj.foo = 2
expect(dummy).toBe(2)
})如果 lazy 为true 的话，那么在执行 effect 的时候，是不会主动执行 run 的，（不会执行 run 就意味着不会执行用户给的 fn），然后执行 effect 之后是会返回 runner 的，这里用户可以自己选择在什么时候去执行
实现也比较简单
export function effect<T = any>(
fn: () => T,
options?: ReactiveEffectOptions
): ReactiveEffectRunner {
if (!options || !options.lazy) {
_effect.run()
}
const runner = _effect.run.bind(_effect) as ReactiveEffectRunner
runner.effect = _effect
return runner
}EffectScope 是什么
暂时看不出来是在哪里使用的
但是他的职责就是收集所有的 effect
计算属性的实现 computed
先从 test 入手
it('should return updated value', () => {
const value = reactive<{ foo?: number }>({})
const cValue = computed(() => value.foo)
expect(cValue.value).toBe(undefined)
value.foo = 1
expect(cValue.value).toBe(1)
})computed 的逻辑
export function computed<T>(
getterOrOptions: ComputedGetter<T> | WritableComputedOptions<T>,
debugOptions?: DebuggerOptions
) {
let getter: ComputedGetter<T>
let setter: ComputedSetter<T>
// 初始化的逻辑
if (isFunction(getterOrOptions)) {
getter = getterOrOptions
setter = __DEV__
? () => {
console.warn('Write operation failed: computed value is readonly')
}
: NOOP
} else {
getter = getterOrOptions.get
setter = getterOrOptions.set
}
const cRef = new ComputedRefImpl(
getter,
setter,
isFunction(getterOrOptions) || !getterOrOptions.set
)
return cRef as any
}一开始先找到 getter 和 setter
接着看 ComputedRefImpl 的实现
class ComputedRefImpl<T> {
public dep?: Dep = undefined
private _value!: T
private _dirty = true
public readonly effect: ReactiveEffect<T>
public readonly __v_isRef = true
public readonly [ReactiveFlags.IS_READONLY]: boolean
constructor(
getter: ComputedGetter<T>,
private readonly _setter: ComputedSetter<T>,
isReadonly: boolean
) {
this.effect = new ReactiveEffect(getter, () => {
if (!this._dirty) {
this._dirty = true
triggerRefValue(this)
}
})
this[ReactiveFlags.IS_READONLY] = isReadonly
}
get value() {
// the computed ref may get wrapped by other proxies e.g. readonly() #3376
const self = toRaw(this)
trackRefValue(self)
if (self._dirty) {
self._dirty = false
self._value = self.effect.run()!
}
return self._value
}
set value(newValue: T) {
this._setter(newValue)
}
}/computed 的核心就是 effect ，而这里是使用了 effect 的 scheduler 的功能
后续执行 effect.run 的时候需要做一些额外的处理
看看 dirty 和 triggerRefValue 是做了什么
因为我们知道 computed 的一个核心点是可以有缓存的，就是没有变化的话，会返回之前的值
主要也是看看 computed 的这个核心功能是如何实现的
先看看 triggerRefValue 的实现
export function triggerRefValue(ref: RefBase<any>, newVal?: any) {
ref = toRaw(ref)
if (ref.dep) {
if (__DEV__) {
triggerEffects(ref.dep, {
target: ref,
type: TriggerOpTypes.SET,
key: 'value',
newValue: newVal
})
} else {
triggerEffects(ref.dep)
}
}
}这里涉及到了 ref 的代码实现了， 哦 算了 ， 计算属性先等等在看，先看 ref ，
这个函数在 ref 的时候都分析完了，可以去看看 ref 的分析
继续
计算属性的话，只有在执行 get 操作的时候才会触发后续的逻辑
构造器里面只是创建了 effect，但是并没有执行
接着就看看 get value 的逻辑吧
get value() {
// the computed ref may get wrapped by other proxies e.g. readonly() #3376
const self = toRaw(this)
trackRefValue(self)
if (self._dirty) {
self._dirty = false
self._value = self.effect.run()!
}
return self._value
}这里的重点是搞清楚 _dirty 的逻辑
选择一个单元测试，使用断点
it('should compute lazily', () => {
const value = reactive<{ foo?: number }>({})
const getter = jest.fn(() => value.foo)
const cValue = computed(getter)
// lazy
expect(getter).not.toHaveBeenCalled()
expect(cValue.value).toBe(undefined)
expect(getter).toHaveBeenCalledTimes(1)
// should not compute again
cValue.value
expect(getter).toHaveBeenCalledTimes(1)
// should not compute until needed
value.foo = 1
expect(getter).toHaveBeenCalledTimes(1)首先是调用了 new ComputedRefImpl
然后再初始化的时候创建了 effect ，这里要注意的是
this.effect = new ReactiveEffect(getter, () => {
if (!this._dirty) {
this._dirty = true
triggerRefValue(this)
}
})
this[ReactiveFlags.IS_READONLY] = isReadonly第二个参数是scheduler 的实现，当执行 effect.run 的时候会执行 fn，当触发了 trigger 逻辑的时候会执行 scheduler 内部的实现
顺序是：
-
执行 new ReactiveEffect
-
用户执行 get value 的操作
-
触发 get
1. _dirty 成false ，锁上了
2. 这里只有在触发了 trigger 的时候才会开锁
-
执行 trackRefValue 收集依赖？这里是处理未知情况的逻辑
-
触发 effect.run()
-
执行用户给的 fn
-
触发收集依赖
-
用户修改了内部响应式对象的值
-
触发 trigger
1. 执行 scheduler 的实现
2. 开锁
- 再次调用 get 的时候 dirty 成 ture 所以可以再次执行 effect.run 也就是执行用户给的 fn
ref 的实现
先从这里看起
export function ref(value?: unknown) {
return createRef(value)
}function createRef(rawValue: unknown, shallow = false) {
if (isRef(rawValue)) {
return rawValue
}
return new RefImpl(rawValue, shallow)
}用户实际使用的就是 RefImpl 的实例
而 refimpl 一共就2个行为， get value 和 set value
class RefImpl<T> {
private _value: T
private _rawValue: T
public dep?: Dep = undefined
public readonly __v_isRef = true
constructor(value: T, public readonly _shallow = false) {
this._rawValue = _shallow ? value : toRaw(value)
this._value = _shallow ? value : convert(value)
}
get value() {
trackRefValue(this)
return this._value
}
set value(newVal) {
newVal = this._shallow ? newVal : toRaw(newVal)
if (hasChanged(newVal, this._rawValue)) {
this._rawValue = newVal
this._value = this._shallow ? newVal : convert(newVal)
triggerRefValue(this, newVal)
}
}
}而基于我们之前看 reactive的经验，知道在 get 的时候是会 track 的，在 set 的时候会 trigger 的
而 ref 这里的实现也是一样的
先看 trackRefValue
export function trackRefValue(ref: RefBase<any>) {
if (isTracking()) {
ref = toRaw(ref)
if (!ref.dep) {
ref.dep = createDep()
}
if (__DEV__) {
trackEffects(ref.dep, {
target: ref,
type: TrackOpTypes.GET,
key: 'value'
})
} else {
trackEffects(ref.dep)
}
}
}这里的实现就简单了，因为一个 ref 只会对应一个值，所以实现的时候会创建一个 dep 赋值给 ref.dep 上
然后后面的执行和 reactive 一样了。都是执行 trackEffects来处理
这里有个问题，如果说传入的值是 object 或者是 array 的话，那怎么办？
答案就是会用 reactive 包裹一下，这个逻辑是在 构造器里面实现的
constructor(value: T, public readonly _shallow = false) {
this._rawValue = _shallow ? value : toRaw(value)
this._value = _shallow ? value : convert(value)
}看 convert 的实现
const convert = <T extends unknown>(val: T): T =>
isObject(val) ? reactive(val) : val
啊哦，如果是个 object 的话，那么就用 reactive 包裹了
那继续去看 set逻辑
set value(newVal) {
newVal = this._shallow ? newVal : toRaw(newVal)
if (hasChanged(newVal, this._rawValue)) {
this._rawValue = newVal
this._value = this._shallow ? newVal : convert(newVal)
triggerRefValue(this, newVal)
}
}这里处理了2个点
- 看看新的值和老的值一样不，如果不一样的话，需要更改之前的值
- 触发 triggerRefValue
export function triggerRefValue(ref: RefBase<any>, newVal?: any) {
ref = toRaw(ref)
if (ref.dep) {
if (__DEV__) {
triggerEffects(ref.dep, {
target: ref,
type: TriggerOpTypes.SET,
key: 'value',
newValue: newVal
})
} else {
triggerEffects(ref.dep)
}
}
}这里也和之前是一样的，如果有 dep 的话，那么就 trigger 一下就可以了
DeferredComputed 的实现
先从单元测试看起
test('should only trigger once on multiple mutations', async () => {
const src = ref(0)
const c = deferredComputed(() => src.value)
const spy = jest.fn()
effect(() => {
spy(c.value)
})
expect(spy).toHaveBeenCalledTimes(1)
src.value = 1
src.value = 2
src.value = 3
// not called yet
expect(spy).toHaveBeenCalledTimes(1)
await tick
// should only trigger once
expect(spy).toHaveBeenCalledTimes(2)
expect(spy).toHaveBeenCalledWith(c.value)
})大概先猜测的话，这里的 deferredComputed 和 computed 大概差不多，一上来就会执行，但是不同的是后续在改变他的值的时候他不会立即执行了。而是等到 await tick 之后才会执行
那看看是如何实现的
程序的入口
export function deferredComputed<T>(getter: () => T): ComputedRef<T> {
return new DeferredComputedRefImpl(getter) as any
}class DeferredComputedRefImpl<T> {
public dep?: Dep = undefined
private _value!: T
private _dirty = true
constructor(getter: ComputedGetter<T>) {
let compareTarget: any
let hasCompareTarget = false
let scheduled = false
this.effect = new ReactiveEffect(getter, (computedTrigger?: boolean) => {
if (this.dep) {
if (computedTrigger) {
compareTarget = this._value
hasCompareTarget = true
} else if (!scheduled) {
const valueToCompare = hasCompareTarget ? compareTarget : this._value
scheduled = true
hasCompareTarget = false
scheduler(() => {
if (this.effect.active && this._get() !== valueToCompare) {
triggerRefValue(this)
}
scheduled = false
})
}
// chained upstream computeds are notified synchronously to ensure
// value invalidation in case of sync access; normal effects are
// deferred to be triggered in scheduler.
for (const e of this.dep) {
if (e.computed) {
e.scheduler!(true /* computedTrigger */)
}
}
}
this._dirty = true
})
this.effect.computed = true
}
private _get() {
if (this._dirty) {
this._dirty = false
return (this._value = this.effect.run()!)
}
return this._value
}
get value() {
trackRefValue(this)
// the computed ref may get wrapped by other proxies e.g. readonly() #3376
return toRaw(this)._get()
}
}这里的几个属性都是和 computed 是一样的，比如有 dep 、 dirty、和 value
看看区别是什么
get 函数的实现和 computed 是差不多的，但是他没有 set 。
get value() {
trackRefValue(this)
// the computed ref may get wrapped by other proxies e.g. readonly() #3376
return toRaw(this)._get()
} private _get() {
if (this._dirty) {
this._dirty = false
return (this._value = this.effect.run()!)
}
return this._value
}同样都是使用 dirty 给锁上
那重点应该就是在 trigger 的实现里面
constructor(getter: ComputedGetter<T>) {
let compareTarget: any
let hasCompareTarget = false
let scheduled = false
this.effect = new ReactiveEffect(getter, (computedTrigger?: boolean) => {
if (this.dep) {
if (computedTrigger) {
compareTarget = this._value
hasCompareTarget = true
} else if (!scheduled) {
const valueToCompare = hasCompareTarget ? compareTarget : this._value
scheduled = true
hasCompareTarget = false
scheduler(() => {
if (this.effect.active && this._get() !== valueToCompare) {
triggerRefValue(this)
}scheduler
scheduled = false
})
}
// chained upstream computeds are notified synchronously to ensure
// value invalidation in case of sync access; normal effects are
// deferred to be triggered in scheduler.
for (const e of this.dep) {
if (e.computed) {
e.scheduler!(true /* computedTrigger */)
}
}
}
this._dirty = true
})
this.effect.computed = true
}这里的 computedTrigger 参数是什么？
这里第二个参数是 scheduler ，我们看看当调用 scheduler 的时候给传入的什么参加就可以了
咦，看了看 effect 里面当调用 scheduler 的时候 并没有什么参数呀？
那执行看看
这个逻辑实在是太绕了。先放弃
这里有个有价值的是，进队列，在异步后执行的实现逻辑
const tick = Promise.resolve()
const queue: any[] = []
let queued = false
const scheduler = (fn: any) => {
queue.push(fn)
if (!queued) {
queued = true
tick.then(flush)
}
}
const flush = () => {
for (let i = 0; i < queue.length; i++) {
queue[i]()
}
queue.length = 0
queued = false
}这里有个缺点就是没有看看进来的 fn 是不是已经收集过的。
effectScope 的实现
当 reactivity 这个库单独拿出去使用的时候，就会出现一系列的问题。
比如创建出来的 effect 变多了，如何去统一的 stop 掉。这个 api 就是解决这个问题的
之前在 vue 中使用的话，所有的 effect 都是和组件绑定在一起的。所以当组件销毁的时候，他会自动的把组件内所有的 effect 都 stop 掉。
先看看他的几个功能点
-
收集所有的 effect
-
包含了 effect
-
watch
-
computed
-
watchEffect
-
可以统一的停止所有的 effect
-
也就是调用收集起来的 effect.stop
-
可以有多个 scope 联合起来使用
-
多个 scope 就会涉及到树结构
-
当 parent scope 清理的时候所有的 children 都会被清理掉
-
也可以设置一下 具体的那个 scope 可以不会被清理
从 api 上来看的话分为以下几个行为：
1. Basic Usage
-
Nested Scopes
-
Detached Nested Scopes
4.onScopeDispose
好了，接下来就依次来看看是如何实现的
看看是如何收集所有的 effect 的
run<T>(fn: () => T): T | undefined {
if (this.active) {
try {
this.on()
return fn()
} finally {
this.off()
}
} else if (__DEV__) {
warn(`cannot run an inactive effect scope.`)
}
}关键函数是 this.on 和 this.off
//this.on
on() {
if (this.active) {
effectScopeStack.push(this)
activeEffectScope = this
}
}咦，这里只做到了把 effectScope 自己收集起来，那在什么时候收集的 run 里面的 effect 呢？
这个问题的答案是在这里 recordEffectScope
export function recordEffectScope(
effect: ReactiveEffect,
scope?: EffectScope | null
) {
scope = scope || activeEffectScope
if (scope && scope.active) {
scope.effects.push(effect)
}
}scope 就是 effectScope 了。而里面的逻辑也很简单 就是把 effect 给收集起来，而这个函数是在哪里调用的呢？
export class ReactiveEffect<T = any> {
constructor(
public fn: () => T,
public scheduler: EffectScheduler | null = null,
scope?: EffectScope | null
) {
recordEffectScope(this, scope)
}哈哈，是在 new ReactiveEffect 的时候，所以只要是 effect 创建了，那么就会收集到当前的 scope 里面了，这样就完成了收集 effect 的动作
这里有个发现是，在创建 effect 的时候，你可以指定具体的 scope 。不然的话 就是 activeEffectScope （当前的 scope 来收集 effect 了）
我们继续去看看 this.off 的实现
off() {
if (this.active) {
effectScopeStack.pop()
activeEffectScope = effectScopeStack[effectScopeStack.length - 1]
}
}可以看到，这里是用 stack 来管理收集递归调用的，这里也和程序执行用 stack 来管理是一样的道理
stop 功能是如何实现的
stop(fromParent?: boolean) {
if (this.active) {
this.effects.forEach(e => e.stop())
this.cleanups.forEach(cleanup => cleanup())
if (this.scopes) {
this.scopes.forEach(e => e.stop(true))
}
// nested scope, dereference from parent to avoid memory leaks
if (this.parent && !fromParent) {
// optimized O(1) removal
const last = this.parent.scopes!.pop()
if (last && last !== this) {
this.parent.scopes![this.index!] = last
last.index = this.index!
}
}
this.active = false
}
}如果只忽略其他功能的话，那么核心只是一行代码
this.effects.forEach(e => e.stop())
把收集起来的所有的 effect 都执行 stop 就完事了
剩下的逻辑是处理其他功能的。我们接着依次去看看
scope 里面会嵌套 scope，当执行 stop 的时候，内部的 scope 里面所有的 effect 也会都 stop，这个是怎么实现的？
如果让我自己来实现的话，那么首先是当前的 scope 应该把内部的所有 scope 都存起来，然后再 stop 的时候在调用内部 scope.stop 逻辑
那么先看看如何存的把：
这里是用 scopes 字段来存储的
scopes: EffectScope[] | undefined
那看看在哪里 push 的把
constructor(detached = false) {
if (!detached && activeEffectScope) {
this.parent = activeEffectScope
this.index =
(activeEffectScope.scopes || (activeEffectScope.scopes = [])).push(
this
) - 1
}
}是在构造器里面执行的 push ，只不过这里判断了 detached 变量，因为在功能的使用上，如果当然的 scope 的 detached 为true 的话，那么表示当前的 scope 是不可以被清理的
又因为 activeEffectScope 是在执行 this.on 的时候才会被赋值，现在还是之前的也就是上一个 scope 所以可以是当前的 scope 的 parent
然后使用 parent 把当前的 scope 给收集起来，这样就完成了收集的处理，
Index 是做什么的， 好像是和后面优化的逻辑相关，暂时不关心
在去看看 stop 时候的处理
if (this.scopes) {
this.scopes.forEach(e => e.stop(true))
}简单 ，和刚刚上面猜测的一样，调用 scope 的 stop 方法就可以了
Detached Nested Scopes 如果 scope 是独立的话，那么当 parent scope 调用 stop 的时候 不应该被清理
这里的实现也很简单了，想一想，如果是 Detached 的话，那么就不应该被清除，那么只需要不收集到 scopes 里面不就完事了吗。 所以在构造器里面的实现就是判断一下
if (!detached && activeEffectScope) {
this.parent = activeEffectScope
this.index =
(activeEffectScope.scopes || (activeEffectScope.scopes = [])).push(
this
) - 1
}detached 是 true 的话，那么你就别给我收集了
onScopeDispose 是类似于组件的 onUnMounted 的功能的
也就是在 stop 执行完成后，被调用。让用户可以处理一些副作用（比如清空一些事件侦听）
export function onScopeDispose(fn: () => void) {
if (activeEffectScope) {
activeEffectScope.cleanups.push(fn)
} else if (__DEV__) {
warn(
`onDispose() is called when there is no active effect scope ` +
` to be associated with.`
)
}
}这里要注意的是， 清理函数是可以有多个的，所以这里是用 数组来存 cleanups
onScopeDispose 的逻辑就是收集所有的处理函数
接着是在 stop 完成之后调用即可
stop(fromParent?: boolean) {
if (this.active) {
this.effects.forEach(e => e.stop())
this.cleanups.forEach(cleanup => cleanup())
if (this.scopes) {
this.scopes.forEach(e => e.stop(true))
}
this.active = false
}
}可以看到，这里的 cleanups 的执行是在 当前 scope 所有的 effect都执行完 stop 之后调用的
知识点
可以利用 stack 来处理递归的每一个状态
使用 Stack 来处理递归嵌套
可以使用二进制的方式来管理多个状态
这里的限制是这个状态只能是个 boolean
问题
targetType 都有哪几种？✅
如何区分触发依赖的时候是 ADD 还是 SET？✅
为什么清空 cleanup ，清空 effect 里面的 deps ✅
执行的代码变了，所以需要全部重新执行
effectsStack 和 trackStack 是为了处理什么场景的？✅
嵌套的场景
一个 stack 需要对应一个 effect
多层级递归调用的 demo 是哪一个 ✅
v8里面的 SMI 是什么？
总结
track 都做了什么
收集依赖
trigger 都做了什
调用收集到的所有的依赖
function ownKeys(target: object): (string | symbol)[] {
track(target, TrackOpTypes.ITERATE, isArray(target) ? 'length' : ITERATE_KEY)
return Reflect.ownKeys(target)
}
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent