How does Vue.js's reactive data system work and what's the underlying logic behind it?

28 Tem 10:55

In Vue 3, the reactivity system has fully transitioned from `Object.defineProperty` to `Proxy`, enabling Vue to perform fine-grained dependency tracking across any level and any type (including arrays, Maps, Sets, etc.). Whenever you wrap state with `ref` or `reactive` in the `setup` function, Vue creates a Proxy for the corresponding object and records the current effect (i.e., the component's render function) in the dependency set of that property when it's accessed. When the property is modified, the Proxy triggers the corresponding dependency's scheduler, scheduling a batch update that ultimately follows the `queueJob → flushJobs` process, calling the component's `render` method. Thus, the "trackable + render" data flow is: `Proxy → Dependency Collection → Scheduling → Component Update → Virtual DOM Diff → Real DOM Patch`. In real projects, I often extract business state into separate `stores` (using `reactive` or `Pinia`) and only read the necessary subsets inside components via `computed`/`watch`, which helps avoid unnecessary full re-renders. Performance bottlenecks typically occur in two places: ① Deep updates on large objects can cause the entire dependency tree to be re-traversed—it's recommended to split them into multiple smaller `reactive` blocks or wrap primitive types with `ref`; ② Frequently triggered side effects (e.g., scroll listeners, network polling) placed directly in reactive data can lead to a render being scheduled every time the state changes. The best practice is to add `flush: 'post'` or `debounce` in `watch`, or even manually control update timing using `scheduler`. For maintainability, keeping reactive data flow unidirectional, avoiding direct prop modifications in `setup`, and exposing APIs that return immutable references (e.g., `readonly`) are key to preventing implicit side effects. This approach leverages Vue 3's Proxy optimizations while ensuring predictability and maintainability in complex business logic.

28 Tem 12:54

In Vue 3, the reactivity system primarily relies on Proxies, where state objects are replaced with reactive proxies (using traps). When a property is accessed inside `setup` or `computed`, the current effect is registered as a "listener" for that property; modifying the value triggers the "effect" to re-run all associated effects, updating the virtual DOM and re-rendering only the affected components. This combination of dependency tracking and rendering ensures changes propagate with minimal overhead. With the Composition API, the `ref` and `reactive` functions define reactivity boundaries more explicitly. `ref` wraps primitive values and exposes `.value`, while `reactive` deeply converts objects into Proxies, allowing tracking of any change within the structure. `computed` creates derived properties that only recalculate when their sources change, reducing unnecessary renders. Additionally, the Effect Scope API enables grouping effects within components or functions, simplifying cleanup when a component unmounts. Key performance and maintenance considerations include: 1) Avoid creating new `reactive` objects on every render; hoist them outside `setup` or use `provide/inject` to minimize overhead. 2) Manually track dependencies when working with external libraries that don’t support Proxies, as this can lead to "effect leaks." 3) Be cautious when modifying deep properties in `reactive` objects without explicit `trigger` calls, as some browsers may not detect changes in Arrays or Maps accurately. What about a scenario where the same `reactive` object is shared across multiple components via `provide/inject` and modified concurrently? Could this lead to unexpected effect re-runs, or does the Proxy system handle it efficiently?