1樓：
我個人是無感啦，目前完全不想用這語法。
我說一下我現在的用法： tsx
export
default
defineComponent
();/* computed */
const
doubleCount
=computed
(()=>
state
.count*2
);/* methods */
const
handleClick=()
=>state
.count++;
/* render */
return
()=>
computed: $`
,return
(<> model =type ="number" /> p>);}; }}); 用tsx，什麼return？？ 什麼export？？ tsx裡面可以用v-model，簡直爽到不要不要的。 state 可以理解為命名空間或者module什麼的，就不用ref了。 compted是計算屬性，const 想改是要報錯的，.value用法特殊一點也沒啥吧。 說心智負擔？試試隔壁家的最佳實踐都不好意思開口。 provide, inject讓我把VueX都直接扔了好麼。 最後我再說一遍，tsx裡面可以用v-model，簡直爽到不要不要的。 2樓：Pony zhang 尤大提出這個糖語法並不是要去創造一種方言，只是在我們真正去選擇用vue3去開發的時候，用到ref的時候一些不習慣用.value去改變變數的人，能有個選擇只是乙個A||B的過程，NG和React也提出了很多小的改動也沒有符合TE37，還不是用的好好的，framework的作者提出乙個新的寫法只是為了我們這些普通的開發者能夠更方便的去使用，沒有什麼可以異議的，加油尤大。 3樓：蝸牛老濕-大聖 寫了點我的看法，先說結論 我其實也不喜歡ref:這個語法，但是更不喜歡社群對這個提案的不包容，方言一定不好嗎？標準就一定好嗎？ 前端圈要以和為貴，應該在普及普通話的基礎之上，各地有意思的方言也要大力推廣 ， 內容移步專欄 蝸牛老濕：Vue3的Ref提案到底發生腎摸事了 4樓：馮恆智 我個人感覺這個問題不值得搞乙個語法糖去解決（和jsx對比），我目前暫時看不出這個語法糖能像jsx那樣甜 jsx目的非常直接，就是把React.createElement換種寫法，而不是去隱藏什麼東西，而ref語法糖提案目的則是去隱藏.value的，寫起來會有種引入了很多隱式的東西的感覺，個人感覺算不上一種好設計 而且jsx是新創造了一種syntax，而不是改變乙個舊有幾乎無人使用的syntax的語義 像svelte也有用使用標籤語法來實現響應式，但這不算是語法糖了，因為js本身沒有語法層面宣告reactivity的能力，如果不想在執行時實現reactivity就必須要引入新語法了，在這個前提下使用label標籤語法比自己發明新語法更安全，自己發明語法有在未來與官方新語法有衝突的風險 5樓：夜無趣 這沒什麼，好處就是多了個特別標記，少寫點看上去很蠢的.value。壞處是，不了解的人看到了還以為是搞了什麼很特別的魔法，實際上也只是編譯器多幹了乙份轉譯活兒而已 6樓： 從心智負擔的角度考慮，要麼全上.value，要麼全省略.value，負擔才是最低的。 現狀是，某些時候省略.value，某些時候又不能省，各種規則真的有點繁瑣。 所以現狀才是最不好的。 個人傾向：不用任何處理直接.value打天下->ref語法糖->現狀 7樓：普通前端阿卡君 目前認為Vue的最大問題的是： 起初Vue給人定位就是親民，並且編碼風格近乎被官方牽著走，所以OptionsAPI給人感覺就是上手特別快的錯覺，以至於培訓機構輸送大批的【精通vue，了解js的程式設計師】。 現在CompositionAPI最大的感覺就是一下子什麼許可權都交給你開發者，很多開發者陷入一頓迷茫不知道vue3應該怎麼寫，相當更缺少乙份明確的風格指南一樣。 所以我覺得語法糖很多時候都可以接受，心智負擔更多是擔心於專案大了之後由於對語法糖本質認知不足情況抱著顧慮，而邁不開這一步。（我倒是挺樂意有語法糖這樣我寫業務快點老闆也高興他不香嘛（bushi ） 順帶一提~建議【只會Vue而不會JS的前端】早點轉行吧，因為Vue會越來越複雜咯~~~。 8樓：Jim Liu 很大原因也是，反過來會擔心vue核心團隊的主要精力去搞這些東西，又導致對於IE11相容包、expose（https:// ）這類看起來不怎麼酷，但是我來說收益很高甚至是必須的部分被降低優先順序，以至於我遲遲無法把專案公升級到vue 3。 9樓： 瀏覽器廠商應該直接提供和 let，const , var 平級的 ref 關鍵字。。。一步到位。 這是個對新手友好的語法糖，況且實踐出真知，反正解決 .value 的問題是很好的方式。程式語言是語言，語言結合大時代背景會有新的變化。 中文不也一樣麼，恐龍，打醬油等等傳統詞語都被時代賦予了新的含義？ 知乎槓精多，怕，匿，懂？ 10樓：張三 可以看出，尤大已經和社群產生分歧了，vue本身的定位就是面向新手，對初級開發更友好。 然鵝，當使用基數大到一定程度以後，很多人就不想繼續為新手服務了，尤大也無法繼續控制社群了，因為已經不是尤大乙個人的專案了。 可以想見，如果.vue單檔案元件的提案到今天，也是不會被通過的，社群會說，你為啥脫離js造乙個.vue的語法？你這是新增方言，增加心智成本！ 11樓：楊劍鋒 Vue 解決的是 UI 範疇的問題，而 js 只是乙個工具罷了，ref 語法糖以最小的代價帶來了更好的抽象，這對解決問題是有很大幫助的，忽視這一點，陷入對語言的宗教崇拜，實屬本末倒置了。 我從 Svelte 3 出來就非常看好，尤其 '$' 的加入更認為是點睛之筆。個人認為未來的方向會是出現一門更適合 UI 領域的新語言，而 Svelte 和 Vue 以這種極小的代價，向前邁出了一大步，這著實令人興奮。 可以看看 Svelte 作者 Harris 的解釋，可以把這種實現理解為是一種更適合響應性 UI 程式設計的新語言。 歸根到底，就是 js 中值和引用是兩種不同的傳遞方式，這才是加重了心智負擔，並導致了一系列的問題。React 偏好值傳遞，但對於複雜型別沒有辦法很好地處理；Vue 偏好引用傳遞，同樣，對於基礎型別，就只能通過 .value 去處理。 ref 語法糖的出現就是為了將傳遞方式進行統一，都視為是引用傳遞。 大家沒必要對 js 過於執迷了，語言也是在不停進步的，jsx 現在也不是 js 標準吧，不也用得好好的，scss/less 也不是 css 標準，也沒見人噴的這麼慘，心態開放一點吧，能解決實際問題才是最重要的。 12樓：不工 這個提案千萬別通過，會毀了vue。 vue現在相比於react和angular最弱的就是js層面抽象能力太弱，這麼一搞，更呆、更亂了。 搞VueScript是沒有前途的。 13樓： 這是乙個極其危險的訊號 因為修改js語義意味著與生態脫節，而vue的團隊說實話還不能自給自足打完一整個生態。 目前來看label語義的修改並不會過多影響，但是會導致開發者對以後vue的生態相容性產生疑慮從而丟失開發者。 在web的世界裡，與標準脫離的，沒有乙個有好下場，除非倒逼標準，否則沒有漏網之魚。 14樓： 這就體現出react和vue的區別了，react感覺無論怎麼改骨架不會變，寫起來依然行雲流水，vue時不時就要對照文件來寫了 15樓：Cyandev 僅表達觀點，非噴。 感覺這個提案的初衷是好的，對於沒有學過 JS 的人來說可以不用理解值型別引用型別的區別，按那個語法宣告的一切變數皆 reactive。 但是對於很熟悉 Vue 的人來說，這個提案的作用看起來就很小了，真的能減少很多 boilerplate 嗎，其實也未必。相反，增加了這麼多語法，會讓 Vue 看起來不是那麼 concise，文件也會變得非常臃腫。 其實我更傾向於乙個庫的 core 是很輕的，僅包含必要的功能，而提案中的這些功能可以通過外掛程式或者其他庫來實現。就像 React Hooks 一樣，幾個 primitive hooks 不得不在 reconciler 層面實現，但除它們以外的任何 hooks 都可以抽出去。 16樓：克瑞斯 rfc是我給提交的沒想到就真給做出來了 爭議大也是意料之中的事情… 不過vscode外掛程式已經有人在跟進了 整體功能的實現肯定沒什麼問題的 17樓：伊撒爾 最新更新： 突然就被當成不看 RFC 的傻白甜還是有點受寵若驚的 我的觀點其實還好，關鍵看 vue 接下來的發展方向，是否會繼續抄 svelte 如果以這個為方向，API 其實是無關緊要的，我們知道你這是在編譯，那你無論怎麼方言都沒關係 如果不打算抄，那這個 API 再怎麼好用也白搭，就算是標準語法，也是個不標準的語義 就一句話：抄！還是不抄！ 以下是原回答： 使用 label syntax 是抄的 svelte API Docs Svelte 俺從三個方面說一下： ref 本身 ref 是否需要乙個超出 js 標準和語義的語法糖，這個我認為是有必要的 是的你沒有看錯，從 ref 本身，也就是引用問題本身來說，是需要有乙個語法糖的，因為從本質上，這就是 js 語言層面的問題，但其實換個模樣會更好些： let= reactive ()這樣就會合理得多，而不是使用 label syntax 單純說 labal syntax，其實是很不標準的，我們平時除了跳出外層迴圈的時候會用，基本沒有在嚴格模式下用過 out: while (true )所以儘管這是乙個標準語法，也已經在廢棄的邊緣不斷試探了 但是無論如何，ref 的問題，別無他法，只能通過新的語法糖去解決 2. 從框架設計角度 如果是從框架角度，這確實不是個好東西，本身組合就亂的一批，現在編譯階段又瞎搞新標準 最終肯定是亂上加亂…… vue 總是這樣，問了解決乙個問題，總是製造更多的問題 為了解決 this 和邏輯復用的問題，搞了 composition API，有了 ref 和 return 的問題 為了解決 ref 和 return 的問題，造了 ref: 語法糖和 svelte 的編譯風格 但是你想想啊，options API 廢除了嗎？沒有，this 問題仍舊存在，大家會只使用新的語法糖嗎？不會，ref 問題一直都在 最終的結果就是所有的問題都沒有消失，一鍋粥搞在一起，憋屈死了 所以從框架角度，這一整套設計就是四個字：沒事找事 3. 編譯大門 新的語法糖意味著 vue 團隊之前說的保持 js 語義等於白說，一旦動了 js 的標準和語義，那我還用什麼 reactivity？ 我直接和 svelte 那樣，基於分配搞響應式不就完了？搞什麼 Proxy 哦…… 我直接原生搞響應式標準不好嗎？ 所以從 ref 問題本身，這是乙個語言特性的缺失，除了製造新的語法糖，別無他法；但是從框架設計角度，沒事找事，通過製造問題解決已有問題的方式不值得提倡；從編譯角度，不如 svelte 未來對於 vue 而言，最好的情況是，w3c 或 tc39 搞乙個新的標準，就像 async/await，但我覺得無論標準如何，都不會使用 label syntax 的 比如這個：rbuckton/proposal-refs 最壞的結果就是沒有未來，vue3成為angular，使用者不樂意給框架作者自己的固執買單了 補充一下，通過編譯，不使用 Proxy 實現響應式的思路 鬧來黑白 其實今年沒怎麼追創，結果B站給我推了PLMM的舞台，5566的封面真是殺瘋了，4vocal的組合太香了。然後看了抒情版的超A，Nene yyds！ 感覺一般般，沒有太驚豔，感覺鵝有點太心急了，還是要多練練，想要在兩年以內達到火少的高度就不要想了，能不能超過同期女團就不錯了 希望企鵝把錄播的... 我是反義詞 給我的感覺是前面看開開心心，高高興興，我還笑了好多次，到了寵物那裡就是不斷的淚目了，尤其是乙個個說養寵物的經歷時，璇璇說到最後也把自己說哽咽了，關鍵是後面nene劉姐說的時候，我真的也繃不住了，劉姐說的時候徹底感動到我了 前半段有趣後半段無趣。我更想看她們玩，哪怕就是做那訪談接梗都比說寵... 大家好我是李瞳瞳 第一反應就是要被眾多苦逼前端罵成狗.馬上滿十年職業生涯，大部分時間在寫前端，我覺得做為前端開發人員，一要懂得妥協，二要擁抱變化。佔坑 強答一波，對我來說有意義的feature 原生的class支援，當然肯定對ts支援和靜態分析比寫引數要好 fragment portal，目測應該是...如何評價硬糖少女303的《硬糖定律》首唱會舞台？
如何評價硬糖少女303的新團綜《硬糖少女BON US》第五集？
如何評價尤雨溪發布的 Vue 3 0 開發計畫？