Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missleading rendering: Ref or computed inside non-wrappable variables (objects, arrays) which returns a string #5578

Closed
Rolanddoda opened this issue Mar 13, 2022 · 1 comment · Fixed by #7306
Labels
🍰 p2-nice-to-have Priority 2: this is not breaking anything but nice to have it addressed. ✨ feature request New feature or request

Comments

@Rolanddoda
Copy link

Version

3.2.31

Reproduction link

sfc.vuejs.org/

Steps to reproduce

I know that refs or computed-s inside objects and arrays don't get unwrapped in the templates.
And that's exactly the issue with the code below:

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

const computedInsideArray = [computed(() => "text")];
const refInsideObject = { val: ref("text") };
</script>

<template>
  <div>{{ computedInsideArray[0] }}</div> <!-- "text" >
  <div>{{ refInsideObject.val }}</div> <!-- "text" >
</template>

The solution is to just use .value

What is expected?

Since accessed element is an object which contains a .value property, an object should be rendered:

{ "value": "text" }

What is actually happening?

"text" (with quotes) is rendered.


In many cases, it can be easy to forget or miss adding .value. And if that happens when a string is returned inside a computed or a ref inside an object or array, it might be difficult to debug since you are going to see the string you want, but inside quotes. And intuitively you might think this is a bug or an issue related to the quotes.

@LinusBorg LinusBorg added ✨ feature request New feature or request 🍰 p2-nice-to-have Priority 2: this is not breaking anything but nice to have it addressed. labels Mar 14, 2022
zscumt123 pushed a commit to zscumt123/core that referenced this issue Mar 16, 2022
@LinusBorg
Copy link
Member

LinusBorg commented Mar 16, 2022

the current behavior was explicitly added here:

f994b97

So we will have to discuss if and if so, when/how we want to change this, and how people that may as of now rely on this, would be affected.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
🍰 p2-nice-to-have Priority 2: this is not breaking anything but nice to have it addressed. ✨ feature request New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants