VUE 3の反応性変換は、手動(dòng)Ref（）またはValueの使用を必要とせずに反応性を自動(dòng)的に追跡および管理することにより、反応データの取り扱いを簡(jiǎn)素化することを目的としています。リアクティブコンテキストで使用された場(chǎng)合、LETやconstのような変數(shù)を自動(dòng)的に活性化するように扱うことにより、ボイラープレートを削減し、コードの読みやすさを改善しようとしました。內(nèi)部的には、

Vueの反応性変換は、VUE 3で導(dǎo)入された実験機(jī)能であり、開発者がリアクティブデータとの相互作用を簡(jiǎn)素化することを目的としています。 ref()やreactive()のような関數(shù)を使用して変數(shù)を手動(dòng)でラッピングする代わりに、アイデアは、どの変數(shù)をリアクティブにする必要があるかを自動(dòng)的に追跡することにより、反応性をよりシームレスで直感的にすることでした。

それは最終的にVUEに長(zhǎng)期にとどまることはありませんでしたが、その目標(biāo)と早期の実裝は、開発者の経験と、フレームワークが反応性をより効率的に処理する方法について多くの議論を引き起こしました。

それはどのような問題を解決しようとしていましたか？

反応性変換の主な目標(biāo)は、反応?duì)顟B(tài)で作業(yè)するときに、ボイラープレートを減らし、読みやすさを向上させることでした。構(gòu)成APIを使用した標(biāo)準(zhǔn)VUE 3セットアップでは、しばしば次のようなことを書きます。

 const count = ref（0）

次に、 countを更新または読み取りたいたびに、 .valueを使用する必要があります。これは問題ありませんが、特にVueを初めて使用する人や、より少ない構(gòu)文が多いアプローチを好む人にとってはノイズが追加されます。

反応性変換は、特定の変數(shù)（ letやconstなど）がリアクティブコンテキストで使用された場(chǎng)合（ setup()関數(shù)內(nèi)または時(shí)計(jì)のコールバック內(nèi)）場(chǎng)合に自動(dòng)的に反応するものとして扱うことを提案します。それは書くことを意味しました：

 count = 0とします

そして、それを直接更新するだけです：

カウント

.valueまたはlapping in ref()を必要とせずに。コンパイラはこれを検出し、フードの下で反応性を管理します。

フードの下でどのように機(jī)能しましたか？

Vueのコンパイラ（特に<script setup></script>パーサー）がここで中心的な役割を果たしました。有効にすると、反応性変換はコンパイル時(shí)間で機(jī)能しました - ランタイムではなく、アプリの実行中にパフォーマンスコストはありませんでした。

舞臺(tái)裏で起こったことは次のとおりです。

• let 、 var 、またはconstで宣言された変數(shù)は、refsとして自動(dòng)包裝できます。
• これらの変數(shù)がリアクティブコンテキスト（テンプレートなど）で使用された場(chǎng)合、システムは変更された更新の変更を保証します。
• 割り當(dāng)て式（ countなど）は、適切な.value変異に自動(dòng)的に変換されました。

これにより、Vueの既存の反応性システムのパフォーマンスの利點(diǎn)を維持しながら、コードがより簡(jiǎn)単に見えました。

なぜ削除されたのですか？

その約束にもかかわらず、反応性変換にはいくつかの欠點(diǎn)があり、その除去につながりました。

• 初心者の混亂：通常のJavaScript変數(shù)とリアクティブな変數(shù)の間の境界線が曖昧になりました。多くの場(chǎng)合、人々は1つの方法で機(jī)能し、他の変數(shù)が機(jī)能しなかった理由を忘れてしまいました。
• エッジのケースと矛盾：自動(dòng)検出が失敗または予期せず動(dòng)作したという難しいシナリオがありました。
• ツールの複雑さ：編集者とリナーは、どの変數(shù)が本當(dāng)に反応的であるかを理解するのに苦労し、オートコンプリートとエラーの検出をより困難にしました。
• コミュニティフィードバック：多くの開発者は、コードの動(dòng)作をより明確にしたため、明示的な反応性（ ref()および.valueを介して）を好みました。

これらの問題のために、Vueのコアチームは、実際に何が起こっているのかを隠さずに同様のDXの改善を提供するマクロ（ $ref 、 $computedなど）などの代替アプローチを後退させて探索することを決定しました。

それから何を?qū)Wぶことができますか？

反応性変換が削除されましたが、開発者の経験の観點(diǎn)から可能なことの境界を押し広げました。それはそれを示しました：

• ボイラープレートが少ないと、よりクリーンで読みやすいコードにつながる可能性がありますが、明確さが犠牲にされない場(chǎng)合のみです。
• 自動(dòng)システムは、混亂を避けるために堅(jiān)実なツーリングサポートが必要です。
• 開発者の期待と學(xué)習(xí)曲線は、技術(shù)的な実現(xiàn)可能性と同じくらい重要です。

反応性変換の背後にあるアイデアのいくつかは、反応性構(gòu)文変換（ $ref()やその他のヘルパーを許可する）などの提案でライブでライブで変換され、VUEチームがまだ反応性を操作しやすくする方法を積極的に調(diào)査していることを示しています。

したがって、反応性変換は固執(zhí)しませんでしたが、Vueの將來の方向性を形作り、フレームワークが狀態(tài)と反応性をどのように処理するかについてのエコシステム全體での會(huì)話を促しました。

以上がVueの反応性変換（実験、削除）とその目標(biāo)の重要性は何ですか？の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。