① React 18 發布、Vue 3、Vitest、Pinia 正式成為 Vue 官方推薦的狀態
Pinia 終於轉正了，它具有與 Vuex 5 幾乎完全相同或者增強的 API，簡單來說，它就是和 Vuex 5 名字不同。Vuex 3 和 4 仍會繼續維護，但是新功能不太可能會添加了。Pinia 也支持漸進式遷移，Vuex 和 Pinia 可以安裝在同一個項目中，新項目的話建議直接使用 Pinia。
Vite 發布了 v2.9.0。
React 18 終於發布了，官方團隊從 v16 就開始普及並發概念，到正式版發布時難免少了一些新鮮感。照目前的發展趨勢看，React 未來會朝著前端底層「操作系統」的方向發展，會變得越來越復陪笑陪雜。這些復雜的操作又會被元框架(Next.js、Remix)消化掉，開發者並不會直接接觸，使用這些元框架開發即可。
穩定不停滯，支持增量升級，v5、v6 的版本代碼可以同時存在。
下面是其他的發布信息和 TC39 提案的一些推進情況，大家可以找感興趣的自行查閱。
下面我們來看技術資料。
和好朋友卡頌一起在做的項目： 前端賞金獵人 。
這是一個用單純的金錢關系維系的前端學習社區，懸賞答題 + 答題賺錢。
期待你的加入，如果覺得有價值的話，可以給個 Star 鼓勵一下。
把技術名詞的大小寫拼蘆蠢寫正確是基本的素養，但很多人都不重視，這個項目可以幫助你糾正錯誤的大小寫。
免費的編程中文書籍索引，項目已有 90.1k Star。
從 2008 年穀歌瀏覽器推出至今的 100 個精彩瞬間回 憶錄。
在這里插入圖片描述
Pinia 是 Vue.js 的輕量級狀態管理庫，最近很受歡迎。它使用 Vue 3 中的新反應系統來構建一個直觀且完全類型化的狀態管理庫。
Pinia的成功可以歸功於其管理存儲數據的獨特功能（可擴展性、存儲模塊組織、狀態變化分組、多存儲創建等）。
另一方面，Vuex也是為Vue框架建立的一個流行的狀態管理庫，它也是Vue核心團隊推薦的狀態管理庫。 Vuex高度關注應用程序的可擴展性、開發人員的工效和信心。它基於與Rex相同的流量架構。
在這篇文章中，我們將對Pinia和Vuex進行比較。我們將分析這兩個框架的設置、社區優勢和性能。我們還將看一下Vuex 5與Pinea 2相比的新變化。
Pinia 設置
Pinia 很容易上手，因為它只需要安裝和創建一個store。
要安裝 Pinia，您可以在終端中運行以下命令：
該版本與Vue 3兼容，如果你正在尋找與Vue 2.x兼容的版本，請查看v1分支。
Pinia是一個圍繞Vue 3 Composition API的封裝器。因此，你不必把它作為一個插件來初始化，除非你需要Vue devtools支持、SSR支持和webpack代碼分割升斗的情況：
在上面的片段中，你將Pinia添加到Vue.js項目中，這樣你就可以在你的代碼中使用Pinia的全局對象。
為了創建一個store，你用一個包含創建一個基本store所需的states、actions和getters的對象來調用 defineStore 方法。
Vuex 也很容易設置，需要安裝和創建store。
要安裝Vuex，您可以在終端中執行以下命令：
要創建store，你可以使用包含創建基本store所需的states、actions和 getter 的對象調用 createStore 方法：
要訪問 Vuex 全局對象，需要在 Vue.js 項目根文件中添加 Vuex，如下所示：
使用 Pinia，可以按如下方式訪問該store：
請注意，在訪問其屬性時省略了 store 的 state 對象。
使用Vuex，可以按如下方式訪問store：
這兩個狀態管理庫都相當容易學習，因為它們在 YouTube 和第三方博客上都有很好的文檔和學習資源。對於以前有使用 Rex、MobX、Recoil 等 Flux 架構庫經驗的開發人員來說，他們的學習曲線更容易。
這兩個庫的文檔都很棒，並且以對經驗豐富的開發人員和新開發人員都友好的方式編寫。
Pinia和Vuex都非常快，在某些情況下，使用Pinia的web應用程序會比使用Vuex更快。這種性能的提升可以歸因於Pinia的極輕的重量，Pinia體積約1KB。
盡管Pinia是在Vue devtools的支持下建立的，但由於Vue devtools沒有暴露出必要的API，所以一些功能如時間旅行和編輯仍然不被支持。當開發速度和調試對你的項目來說更重要時，這是值得注意的。
Pinia 將這些與 Vuex 3 和 4 進行了比較：
這些是Pinia在其狀態管理庫和Vuex之間的比較中提出的額外見解：
將 Pinia 2（目前處於 alpha 階段）與 Vuex 進行比較，我們可以推斷出 Pinia 領先於 Vuex 4。
Vue.js核心團隊為Vuex 5制定了一個開放的RFC，類似於Pinia使用的RFC。目前，Vuex通過RFC來盡可能多地收集社區的反饋。希望Vuex 5的穩定版本能夠超越Pinea 2。
據同時也是 Vue.js 核心團隊成員並積極參與 Vuex 設計的 Pinia 的創建者（Eardo San Martin Morote）所說，Pania 和 Vuex 的相似之處多於不同之處：
盡管 Pinia 足以取代 Vuex，但取代 Vuex 並不是它的目標，因此 Vuex 仍然是 Vue.js 應用程序的推薦狀態管理庫。
根據我的個人經驗，由於Pinea是輕量級的，體積很小，它適合於中小型應用。它也適用於低復雜度的Vue.js項目，因為一些調試功能，如時間旅行和編輯仍然不被支持。
將 Vuex 用於中小型 Vue.js 項目是過度的，因為它重量級的，對性能降低有很大影響。因此，Vuex 適用於大規模、高復雜度的 Vue.js 項目。
批處理是 React將多個狀態更新分組到單個重新渲染中以獲得更好的性能。
例如，如果你在同一個點擊事件中有兩個狀態更新，React 總是將它們分批處理到一個重新渲染中。如果你運行下面的代碼，你會看到每次點擊時，React 只執行一次渲染，盡管你設置了兩次狀態：
這對性能非常有用，因為它避免了不必要的重新渲染。它還可以防止你的組件呈現僅更新一個狀態變數的「半完成」狀態，這可能會導致錯誤。
這可能會讓你想起餐廳服務員在你選擇第一道菜時不會跑到廚房，而是等你完成訂單。
然而，React 的批量更新時間並不一致。例如，如果你需要獲取數據，然後更新handleClick上面的狀態，那麼 React不會批量更新，而是執行兩次獨立的更新。
這是因為 React 過去只在瀏覽器事件（如點擊）期間批量更新，但這里我們在事件已經被處理（在 fetch 回調中）之後更新狀態：
在 React 18 之前，我們只在 React 事件處理程序期間批量更新。默認情況下，React 中不會對 promise、setTimeout、本機事件處理程序或任何其他事件中的更新進行批處理。
從 React 18 開始createRoot，所有更新都將自動批處理，無論它們來自何處。
這意味著超時、承諾、本機事件處理程序或任何其他事件內的更新將以與 React 事件內的更新相同的方式進行批處理。
我們希望這會導致更少的渲染工作，從而在你的應用程序中獲得更好的性能：
注意：作為採用 React 18 的一部分，預計你將升級到createRoot。舊行為的render存在只是為了更容易地對兩個版本進行生產實驗。
無論更新發生在何處，React 都會自動批量更新，因此：
行為與此相同：
通常，批處理是安全的，但某些代碼可能依賴於在狀態更改後立即從 DOM 中讀取某些內容。對於這些用例，你可以使用ReactDOM.flushSync()選擇退出批處理：
2、Suspense 的 SSR 支持
這基本上是伺服器端渲染 (SSR) 邏輯的擴展。在典型的 React SSR 應用程序中，會發生以下步驟：
典型 SSR 應用程序的問題在於，在下一步可以開始之前，必須立即完成整個應用程序的每個步驟。這會使您的應用程序在初始載入時變慢且無響應。
React 18 正試圖解決這個問題。 組件已經以這樣的方式進行了革命性的改變，它將應用程序分解為更小的獨立單元，這些單元經過提到的每個步驟。這樣一旦用戶看到內容，它就會變成互動的。
我們將狀態更新分為兩類：
單擊、懸停、滾動或打字等緊急更新需要立即響應以匹配我們對物理對象行為方式的直覺。否則他們會覺得「錯了」。
然而，轉換是不同的，因為用戶不希望在屏幕上看到每個中間值。
例如，當您在下拉列表中選擇過濾器時，您希望過濾器按鈕本身在您單擊時立即響應。但是，實際結果可能會單獨轉換。
一個小的延遲是難以察覺的，而且通常是預料之中的。如果在結果渲染完成之前再次更改過濾器，您只關心看到最新的結果。
在典型的 React 應用程序中，大多數更新在概念上都是過渡更新。但出於向後兼容性的原因，過渡是可選的。
默認情況下，React 18 仍然將更新處理為緊急更新，您可以通過將更新包裝到startTransition.
構建流暢且響應迅速的應用程序並不總是那麼容易。有時，諸如單擊按鈕或輸入輸入之類的小動作可能會導致屏幕上發生很多事情。這可能會導致頁面在所有工作完成時凍結或掛起。
例如，考慮在過濾數據列表的輸入欄位中鍵入。您需要將欄位的值存儲在 state 中，以便您可以過濾數據並控制該輸入欄位的值。您的代碼可能如下所示：
在這里，每當用戶鍵入一個字元時，我們都會更新輸入值並使用新值來搜索列表並顯示結果。
對於大屏幕更新，這可能會導致頁面在呈現所有內容時出現延遲，從而使打字或其他交互感覺緩慢且無響應。
即使列表不是太長，列表項本身也可能很復雜並且每次擊鍵時都不同，並且可能沒有明確的方法來優化它們的呈現。
從概念上講，問題在於需要進行兩種不同的更新。第一個更新是緊急更新，用於更改輸入欄位的值，以及可能會更改其周圍的一些 UI。
第二個是顯示搜索結果的不太緊急的更新。
用戶希望第一次更新是即時的，因為這些交互的本機瀏覽器處理速度很快。但是第二次更新可能會有點延遲。
用戶不希望它立即完成，這很好，因為可能有很多工作要做。（實際上，開發人員經常使用去抖動等技術人為地延遲此類更新。）
在 React 18 之前，所有更新都被緊急渲染。
這意味著上面的兩個狀態仍然會同時呈現，並且仍然會阻止用戶看到他們交互的反饋，直到一切都呈現出來。我們缺少的是一種告訴 React 哪些更新是緊急的，哪些不是的方法。
新startTransitionAPI 通過讓您能夠將更新標記為「轉換」來解決此問題：
包裝在其中的更新startTransition被視為非緊急處理，如果出現更緊急的更新（如點擊或按鍵），則會中斷。
如果用戶中斷轉換（例如，連續輸入多個字元），React 將拋出未完成的陳舊渲染工作，僅渲染最新更新。
Transitions 可讓您保持大多數交互敏捷，即使它們導致顯著的 UI 更改。它們還可以讓您避免浪費時間渲染不再相關的內容。
上述問題的一個常見解決方案是將第二次更新包裝在 setTimeout 中：
這將延遲第二次更新，直到呈現第一次更新之後。節流和去抖動是這種技術的常見變體。
一個重要的區別是startTransition不安排在以後喜歡的setTimeout是。它立即執行。傳遞給的函數startTransition同步運行，但其中的任何更新都標記為「轉換」。
React 將在稍後處理更新時使用此信息來決定如何呈現更新。這意味著我們比在超時中包裝更新更早地開始呈現更新。
在快速設備上，兩次更新之間的延遲非常小。在較慢的設備上，延遲會更大，但 UI 會保持響應。
另一個重要的區別是 a 內的大屏幕更新setTimeout仍然會鎖定頁面，只是在超時之後。
如果用戶在超時觸發時仍在鍵入或與頁面交互，他們仍將被阻止與頁面交互。但是標記為 的狀態更新startTransition是可中斷的，因此它們不會鎖定頁面。
它們讓瀏覽器在呈現不同組件之間的小間隙中處理事件。
如果用戶輸入發生變化，React 將不必繼續渲染用戶不再感興趣的內容。
最後，因為setTimeout只是延遲更新，顯示載入指示器需要編寫非同步代碼，這通常很脆弱。
通過轉換，React 可以為您跟蹤掛起狀態，根據轉換的當前狀態更新它，並讓您能夠在用戶等待時顯示載入反饋。
您可以使用startTransition來包裝要移動到後台的任何更新。通常，這些類型的更新分為兩類：
總結
React 18 沒有任何重大更改，因此，我們將當前的存儲庫升級到最新版本幾乎不需要更改代碼，但我們可以享受它們很酷的功能。
② Vuejs的VueTool工具開啟失敗解決方案
有時候我們明明打開了devtool設置為true，並按chrome上安裝了vueTool後，發現還是沒有在控制台里顯示vue的tool等問題
1、如果是沒有安裝vueTool，可以到chrome的擴展裡面選擇並安裝
如果是沒有科學上W的話可以github上手動down下倉庫來安裝
然後就是擴展Chrome插件
打開Chrome瀏覽器 >選擇更多工具>擴展程序>打開開發者模式
點擊載入已解壓的擴展程序, 找到剛才生成的chrome文件夾，選擇 vue-devtools > shells > chrome 放入, 安裝成功如上面的圖1
下方是可能可以看到vueTool了，但是在控制台就是出不來的情況
2、檢查下vue.config.js的devtool是否打開，默認是true，看看是不是在非生產環境也設置為false了
3、檢查看看是否有手動啟用CDN加速Vuejs的文件，按官網說的，我們開發環境也需要使用開發版本的vuejs，否則很多警告就會不生效，比如props的校驗器等
檢查public.html的vuejs引用(如果是按腳手架的則無需關注)
確認以上問題以後，我們重新安裝依賴並且重新跑腳手架編譯。