允许使用ref创建一个reactive，或者使用reactive创建一个ref，是否合适？

[kongku]

const count=ref(0);
const state=reactive(count);
watch(state, ()=>{
  console.log("watch callback");
})
state.value=0

1. 单单是这个watch监听state，这个effect.dep数组中就已经有三个Set了，分别对应count，state._value，state.value。
2. 另外，对于state.value的track时，由于ref实例对象自身没有value属性，所以track的type都是ADD，track的type作用不大，就是开发打印信息。但是在对它赋值时，由于判断hadKey为false，即便赋一样的值，也会trigger，只是在effect的job中判断了新旧值所以最终没有调用callback。
3. 在doWatch中，判断source是ref，并且是shallow的时候，就强制trigger，不需要判断新旧值是否一样。那就是说，上面的count或者state其中一个是shallow的情况下（例如，const count=shallowRef(0)），这时候，watch的callback是会执行的。这个意义何在？一直搞不懂这里的用意。

---

const shallow= shallowRef({name: "kk"});
const state = reactive(shallow);
watchEffect(()=>{
  console.log("name", state.value.name);
})
setTimeout(()=>{state.value.name="change"}, 1000)

原本是一个浅层的ref，ref.value就是一个普通的objcet，用来创建reactive后，state.value变成了一个reactive，容易混淆。

[liulinboyi]

I think you can read the documentation, which describes shallowRef in this way:

Unlike ref(), the inner value of a shallow ref is stored and exposed as-is, and will not be made deeply reactive. Only the .value access is reactive. Link

和 ref() 不同，浅层 ref 的内部值将会原样存储和暴露，并且不会被深层递归地转为响应式。只有对 .value 的访问是响应式的。链接

[kongku]

我知道shallowRef的用法，也看过源码，我的问题是监听reactive(shallowRef)，为什么在赋值没变的情况下也要强制trigger（在reactive的set trap中，value不属于raw的key，是添加操作，所以会trigger，在ReactiveEffect的调度器中执行job时，又因为是shallowRef，不判断新旧值，直接调用cb）。
如果只是监听ref，reactive，shallowRef，shallowReactive，在赋值后没变的情况下，根本就不会trigger，即便是reactive(ref)，也会在job中判断新旧值后才决定调用cb。
reactive与shallowRef结合，或shallowReactive与ref结合，就不需要判断新旧值，直接trigger，直接cb？

[liulinboyi]

我知道shallowRef的用法，也看过源码，我的问题是监听reactive(shallowRef)，为什么在赋值没变的情况下也要强制trigger（在reactive的set trap中，value不属于raw的key，是添加操作，所以会trigger，在ReactiveEffect的调度器中执行job时，又因为是shallowRef，不判断新旧值，直接调用cb）。 如果只是监听ref，reactive，shallowRef，shallowReactive，在赋值后没变的情况下，根本就不会trigger，即便是reactive(ref)，也会在job中判断新旧值后才决定调用cb。 reactive与shallowRef结合，或shallowReactive与ref结合，就不需要判断新旧值，直接trigger，直接cb？

Can you provide a demo in playGround ? Only read you reply i can't get it what your means. @kongku