Enhance Vue 3 debugging experience by reducing reliance on proxy wrappings

[tirithen]

Vue 3's proxy-based reactivity system has introduced significant performance improvements but has also created substantial challenges in debugging and inspecting reactive state. This issue aims to address these challenges and explore potential solutions to improve the developer experience, especially when working without Vue DevTools.

Current Challenges:

• Obfuscated State Inspection: Proxy-wrapped objects make it difficult to inspect state directly in browser developer tools, often displaying unhelpful Proxy(Object) outputs instead of actual data.
• Nested Object Complexity: Debugging complex, nested data structures requires navigating through multiple layers of proxy wrappers, significantly slowing down the debugging process.
• Interoperability Issues: Proxy objects can cause unexpected behavior when interacting with external libraries, Web Workers, or when serializing data.
• Dependency on Custom Tools/Tricks: The current system often necessitates the use of either adding/running .toRaw()/JSON.parse(JSON.stringify(object)), Vue DevTools or custom debugging utilities, which may not always be available or preferred.

Proposed Solutions:

• Explore a hybrid approach inspired by Lit's property-based reactivity system:
  • Use getter/setter pairs for reactive properties instead of wrapping entire objects in proxies.
  • Study Lit's signals system (https://lit.dev/docs/data/signals/) and how that integrates with the TC39 Signals proposal.
• Aim for better compatibility with standard JavaScript, making state directly inspectable in browser developer tools.
• Investigate direct integration possibilities with the TC39 Signals proposal (https://github.com/tc39/proposal-signals) for a standardized approach to reactivity that's more debugging-friendly.

Benefits:

• Simplicity for the users! A design like this will always be much more intuitive. It will also feel less magic (as in the confusing kind of code magic).
• Choice of debugging method, as a framework developer it is impossible to foresee all usage patterns the users needs.
• Significantly improved developer experience when debugging Vue applications, especially for developers who prefer native browser tools.
• Better compatibility with standard JavaScript debugging practices and tools.
• Reduced learning curve for new Vue developers.

[jods4]

For sure Proxies come with added challenges, but they also solve some unique issues that no other JS primitive can solve.

Proposed solutions:

Use getter/setter pairs for reactive properties instead of wrapping entire objects in proxies.

This is interesting because it avoids proxy issues and it's much faster. But it has a critical limitation: you can't observe property addition (and rarely: deletion).
Somehow when you make your object reactive you must know all properties that might be added to object. Patterns like const x = reactive({}); x.name = "John" will not work.
In specific contexts you could require that all properties are set at creation (maybe just as undefined). Or you could use a class-based approach, maybe even with decorators for greater flexibility (some properties could be non-reactive, or computed).

A critical special case of this is arrays. Reactive library have traditionally required usage of a getter/setter function to work around this limitation, i.e. array.set(1, array.get(1) + 42) instead of array[1] += 42. It's more efficient but it's not very nice syntax.

I think property-based reactivity is interesting and has use-cases but it's not a substitute for proxies. It could complement proxies, as an alternative where applicable.
If you like this idea, it's not hard to implement this in a userland library for Vue today.

Aim for better compatibility with standard JavaScript, making state directly inspectable in browser developer tools.

This is a goal, not a solution. As proxies are "standard JavaScript", the argument is a little flawed but I get what you mean.
I agree inspection of proxies is not great, but I'm not sure it's sooo bad. The instance is exposed when you expand proxies in developer tools.

Investigate direct integration possibilities with the TC39 Signals proposal (https://github.com/tc39/proposal-signals) for a standardized approach to reactivity that's more debugging-friendly.

As of today, Signals are a limited low-level reactivity primitive that basically exposes the equivalent of Vue ref to manage reactive state. Consumers of Signals are expected to create higher-level abstractions, such as using those ref to implement proxies :)

Saying that TC39 Signals is more debugging-friendly is similar to not using reactive proxies and code everything with shallowRef.

[tirithen]

@jods4 thank you for taking the time to answer. As you can see I do not come with a complete solution, I have however found the proxies a bit hard to work with during the past few years using Vue 3.

True that you can expand them, but working on several larger projects using Vue 3 I find myself slowed down quite a lot when doing console.log style debugging on nested objects.

You do point out a few great points that distinguish Lit from Vue in that Vue Composables often are dynamic objects where it is hard to tell which properties that needs monitoring. Lit reactive properties are of course closer to Vue props. Using a combination of standard custom elements created with Lit and Vue in apps for a long time now I always find the custom elements so much easier to debug.

It would be great with the same simplicity for the Vue system as well, but I see the challenge. JavaScript not having any great hash mechanic to check for equality between objects also makes it a challenge, which makes periodic checking a bit more expensive.

Maybe as you said a class system with "reactive" properties could help a bit as an alternative to composables. Array methods could be overwritten, but direct index assignment with arrays is still a gap.

[leopiccionia]

That's very similar to how Vue 2 worked (see its "Reactivity in Depth" docs).

Vue.set and Vue.delete (or the equivalent $set and $delete instance methods, respectively) were needed for tracking dynamic properties, and forgetting to declare a reactive state in data (a cumbersome chore in deep objects) was perhaps the overall most common source of bugs.

Fixing those issues, and adding reactivity for other native data types (like Map and Set), were some of the factors that made the community enthusiastic when it was announced that Vue 3 would be Proxy-based. It's sad that, after all those years, Proxy debugging capabilities in modern browsers are still missing, but I think Proxy is the right choice considering all the variables.