fix(compiler-sfc) fix setup result binding of primitive (non inlined mode) closes #5655

[lidlanca]

closes #5655

compiled result of a setup in non inlined mode, may lose binding to non reactive primitives

<script setup>
let a = 123
setTimout(()=>{ a++, updateTemplate()}
</script>
<template>
{{a}}
</template>

in inlined mode the template always have the binding to a.
if a changes and view updates, a will reflect the new value

in non inlined mode, the setup result is a snapshot of the value
at the time setup() was called

{a}

a will remain 123, even if a mutated and component re rendered

The fix:

instead of compiling the setup result to

{a}

compile with a getter/setter for any mutable and settable variable to keep a binding to the original variable.

{get a(){ return a}, set a(v){a=v} }

if the variable is only mutable but not settable ( like an es import specifier )
only return getter

import {comp} from "./myLib.js"
...

{get comp(){ return comp}}

[netlify]

✅ Deploy Preview for vue-next-template-explorer ready!

Name	Link
🔨 Latest commit	7c1ac6b
🔍 Latest deploy log	https://app.netlify.com/sites/vue-next-template-explorer/deploys/6262566103a382000945f682
😎 Deploy Preview	https://deploy-preview-5777--vue-next-template-explorer.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for vuejs-coverage ready!

Name	Link
🔨 Latest commit	7c1ac6b
🔍 Latest deploy log	https://app.netlify.com/sites/vuejs-coverage/deploys/626256610659be0008f871a0
😎 Deploy Preview	https://deploy-preview-5777--vuejs-coverage.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[netlify]

✅ Deploy Preview for vue-sfc-playground ready!

Name	Link
🔨 Latest commit	7c1ac6b
🔍 Latest deploy log	https://app.netlify.com/sites/vue-sfc-playground/deploys/62625661ceebc60008da8af4
😎 Deploy Preview	https://deploy-preview-5777--vue-sfc-playground.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[LinusBorg]

I think this fix is the right direction. One thing we need to consider is that I have seen this type of code far too often in setup functions:

let myFlag = ref(false)

return {
  myFlag
}

And I think the current implementation of this fix would break such existing code as it would no longer assign a value from the template and instead reassign the let variable? If so, we could use a isRef check in the setter to catch this.

[lidlanca]

I think this fix is the right direction. One thing we need to consider is that I have seen this type of code far too often in setup functions:

let myFlag = ref(false)

return {
  myFlag
}

And I think the current implementation of this fix would break such existing code as it would no longer assign a value from the template and instead reassign the let variable? If so, we could use a isRef check in the setter to catch this.

@LinusBorg

the fix should work for that use case as well
the getter and setter are transparent, and the unwrapping will still be handled as
expected by shallowUnwrapHandlers of the setupState.

the only case that I am not covering is class and function declaration, which are analyzed as setup-const
but in fact are also settable.

[lidlanca]

the fix can be seen in this playground.
sfc playground, with no inline compiler

[LinusBorg]

he fix should work for that use case as well
the getter and setter are transparent, and the unwrapping will still be handled as
expected by shallowUnwrapHandlers of the setupState.

the only case that I am not covering is class and function declaration, which are analyzed as setup-const but in fact are also settable.

I understand, thanks. TIL you can reassign a function declaration 🤯 Never tried that in my life 😝

[yyx990803]

Thanks a lot for the PR - sorry I noticed this only after pushing 5a3d45a, and realized we do need to consider import bindings as well.

Unfortunately, the diffs between the branches got really messy and it was difficult to resolve the snapshots properly, so I wasn't able to reuse this PR and had to work upon my branch in 0594400. Really sorry for letting this hang for so long and thanks again for you contributions!