Why close the no-ref proposal of #213? I like the no-ref syntax

[alamhubb]

#213

I think the #213 proposal is a very good proposal. I really like the syntax in this proposal, and I don’t like ref() and $(ref()) very much. Why is this proposal closed? Are there any other no-ref solutions?

I looked at #369 carefully, but he only solved the problem of .value, not the problem of ref(). Instead, it added $(ref()). I don’t like it, I want one without ref() Responsive solutions can also be realized, can I provide them in the future

I want

template

{{hello}}

js

<script setup no-ref>
let hello = 'hello world'


setTimeout(()=>{ hello = 'update' },10000)
</script>

Thank you for your selfless dedication, thank you very much

[jods4]

Can you flesh out a proposal how that would work?

Is every single variable declaration in a component gonna be a ref (implicitly)?

• Isn't that gonna be excessive in terms of memory / perf?
• What if I want to create a variable that explicitly isn't reactive, so when it changes it doesn't trigger watches?

Are those refs deep or shallow? What if I want the other option?

Would that be applicable to plain JS code in other modules?
A good point of the current ref sugar proposal is that you could apply it to composable JS code as well.
I don't think "everything is a ref" would scale to regular JS modules, which means more confusion.

[alamhubb]

I'd like to add that this can be a matter of taste / preference.

Aurelia, which I used as an example, values simplicity and "plain JS magically just works". I was in its core team for a while and tried to influence the direction into something more similar to Knockout, but it wasn't something the team wanted to pursue because its users like the "no special syntax" approach and it's a distinctive Aurelia feature.

There's no magic bullet when it comes to observable state, each library has a different approach. I think as a user you need to pick the library that does it in the way you like most.

Can we combine the two methods, automatically processing when it is traceable, and manually processing when it is untraceable, just like $set(), many times we don’t use it, but we can use it if we need it it

[jods4]

Yes, that blend is somehow what Svelte does with its explicit Stores (~Refs) and automatic local component variables.

The hard part is coming up with a system that is sound, blends both ways nicely and is intuitively understandable by devs (Svelte doesn't cut it for me).
Maybe someone can flesh out a clever proposal for that.

[alamhubb]

Yes, that blend is somehow what Svelte does with its explicit Stores (~Refs) and automatic local component variables.

The hard part is coming up with a system that is sound, blends both ways nicely and is intuitively understandable by devs (Svelte doesn't cut it for me). Maybe someone can flesh out a clever proposal for that.

@yyx990803 尤大，Would you consider solving the ref() problem in this way

[yyx990803]

Which is why #369 exists - the idea is not about getting rid of ref() because that's how it works fundamentally without magic. Vue is built with a no-magic foundation with optional magic on top. Vue will never pretend plain JS variables with no special indication can be magically reactive. The distinction between magic vs. no-magic must be explicit. If you want magic-only, then it's fine to just use Svelte.

[alamhubb]

Which is why #369 exists - the idea is not about getting rid of ref() because that's how it works fundamentally without magic. Vue is built with a no-magic foundation with optional magic on top. Vue will never pretend plain JS variables with no special indication can be magically reactive. The distinction between magic vs. no-magic must be explicit. If you want magic-only, then it's fine to just use Svelte.

Why is it magic to automatically determine whether a variable is responsive?

And data binding is not magic, nor is v-model magic?

I think they are all magic, vue is not without magic, data binding and v-model are both magic

I just want to add another magic, not from no magic to magic, I think so