Feature Proposal: Support val$ Syntax Sugar for ref values #998

Clear and concise description of the problem

I used AI as base because english is not my native language, hope it's not too vorbose

As a developer using Vue Macros, I want a simple syntax sugar (val$) for accessing the .value of a ref, so that I can write cleaner and more readable reactive code without losing explicit control over refs.

I really liked the concept behind the original Reactivity Transform, but in practice, the implementation added too much mental overhead. Remembering when to use $ref, $(), or $$() made code less predictable and harder to follow across files.

This proposal aims to keep the spirit of that transform — removing repetitive .value — but do so in a more lightweight and explicit way, without introducing new macro declarations or hidden behavior.

Suggested solution

In the reactivity transform module (or a new one), we could add a new compile-time transform step that recognizes postfix $ identifiers, such as val$, and rewrites them into <identifier>.value.

How it could work

• Verify that a binding for the base variable (e.g. val) exists in the current scope.
  Potentially, it could even recognize variables declared in parent scopes or functions (similar to how reactivity transform currently resolves).
• Rewrite reads, writes, and update expressions accordingly.
• Leave non-Ref identifiers untouched.
• Should be adaptable for TypeScript (I assume, I'm not using TS)

Example

<script setup>
import { ref, computed } from 'vue'

const count = ref(0)
const doubled = computed(() => count$ * 2)

function increment() {
  count$++
}

console.log(doubled$) // → doubled.value
</script>

<template>
  <button @click="increment">
    Count: {{ count }} / Doubled: {{ doubled }}
  </button>
</template>

Alternative

val$ can be replaced with $val or with underscore or even with non valid JS char as # or @

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guide.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.