兩年前，我設計並開發了一個名為alovajs 的 JavaScript 請求策略函式庫。自2023年4月推廣以來，獲得了全球開發者的一致好評，並獲得了超過2700+顆星，其中包括各大公司專家的認可。
目前alova@3.x已經發布，定位為「簡化工作流程的下一代請求工具」
我無償維護了30個月，版本已經到了3.x。這段時間，透過不斷的反思、拒絕、重新思考，我的目標是做到一些其他請求工具沒有做到的事情，成為一個真正能夠幫助前端開發的工具。我相信我已經找到可靠的方向了。
即打造“下一代精簡流程的請求工具”，最大限度地協助前端開發精簡API整合流程。
以下是alovajs的探索故事，也是一個開源專案從誕生開始的故事。
如果你對alovajs有興趣，真誠邀請你加入社區，共同進步。
2022年3月的某一天，由於某些情況，我萌生了開發一款名為「Con of goal」的應用程式的想法。受到一些應用的啟發，我希望「Con of goal」能夠實現無延遲的資料請求和提交，即時回應模式，即使在弱網路或無網路的情況下。然而在網路上搜尋並沒有找到合適的解決方案，而且類似的樂觀更新方案又不能滿足需求，我該死的分享慾望讓我決定以請求庫的形式來實現，這就是alovajs的出發點，但當時還沒有名字。
庫的開始不是設計，不是開發，而是明確需求
專業提示：強烈建議您先簡單了解alovajs的概述部分，以便更好地理解下面的內容。
當時沒有產品定位，只是建立一個JavaScript庫來滿足自己的需求。我研究了現有的請求庫並列出了以下需求：
然後根據需求，設計了庫的API。
針對需求2，設計了三個核心useHook：useRequest、useWatcher、useFetcher。這個大家都很熟悉了，像是ahooks的useRequest、vueuse的useAsyncState、react-query、swr，不用說，確實很方便。
由於採用了useHook設計，不同的框架會有不同的狀態管理，但我不想像react-query那樣為每個框架創建一個JavaScript庫。因此，針對需求3，設計了stateHook適配器、請求適配器、儲存適配器的規範，可以根據規範編寫不同的適配器，將框架環境和執行時間環境相關邏輯分離到單獨的模組中。
針對需求4，設計了方法實例代理模式，方法實例代理調用不同適配器的鉤子函數，這樣即使你開發任何應用，都可以上手alovajs，沒有任何陌生感，而且還可以無縫移植。
對於需求5，類似的JavaScript庫以自訂鍵的形式實現緩存，但我的想法是專注於請求資訊。常見的場景是，用相同的請求方法和參數請求同一個介面時，需要命中上次的回應資料。為什麼我們不使用這些請求資訊作為快取鍵呢？因此，alovajs 設計了一種自動快取機制，在 GET 請求上預設啟用該機制。
需求6，參考axios學習。
這些設計確實已經被時間證明了。 alovajs 透過適配器的方式完美相容了Vue、React、Svelte 框架，並且還可以運行在瀏覽器、React Native、UniApp、Taro 等各種JavaScript 環境中，同時保持了一致的使用方法，這讓我看到了一絲希望。
接下來的幾個月，alovajs雖然發布了，但一直沒有推廣。一方面是因為我在「Con of goal」計畫中使用了它。雖然在這個專案中得到了錘鍊和完善，但還是很不完整，定位不明確。初始版本介紹是這樣的
後來「Con of goal」計畫流產了，但alovajs還在堅持。
懷著曾經當網路產品經理的執念，我還是希望把alovajs打造成一個差異化的產品。我經常問自己，alovajs 和其他請求庫有什麼不同？使用者為什麼要使用alovajs？它在設計上確實與其他庫不同，這不是一個可以立即回答的問題。後來我嘗試將請求庫的方向定位為“輕量級請求庫”和“多端統一請求庫”，但都被自己否定了，因為這些不能給開發者帶來實質性的幫助，也不能才叫優勢。
2022年9月，一個機會讓我發現了基於Vue的優秀請求庫，vue-request。它的 usePagination 和 useLoadMore 立即啟發了我。這種形式的分頁實現讓我意識到這也是我想要的。同時也讓我體認了useHook的強大。我可以根據請求場景來劃分模組，針對不同的場景使用不同的useHooks，而先前實現的無縫資料互動其實也是場景之一。如果是這個方向的話，開發者可以根據不同的請求場景選擇不同的useHooks，這樣不僅提高了開發效率，降低了編碼複雜度，也避免了初級前端寫出低效的程式碼，並且可以更好的利用核心功能alovajs 以實現更好的效能和更少的伺服器壓力。請求特性，至此，「輕量級請求策略庫」是我選擇的。
然後，為了引導alovajs未來的設計方向，我還對alovajs的請求場景模型（RSM）進行了提煉和抽象，主要分為以下四個流程：
Request timing -> Request behavior -> Request event -> Response processing
開始吧，我按照這個定位開始重構alovajs 2.0，將無縫資料互動功能從1.0中分離出來，設計了中間件機制來適應更多請求場景策略的開發useHooks，研究開發了分頁策略和無縫資料互動策略。
alovajs的分頁策略是我認為最有用的usePagination。利用alovajs的快取功能實現前後頁資料預先載入、分頁資料搜尋、請求級去抖，並提供新增編輯刪除功能的自動化管理，以及重新整理指定頁面程式碼的資料無需重設。
無縫資料互動策略花了我4個月的時間，不斷遇到死胡同，不斷重新設計結果。它實現了即使在弱網或斷網環境下也可以讓使用者無延遲地與資料互動的策略，同時也能更穩定地保證請求的成功。我設計了一個虛擬資料的東西，可以在回應前作為回應資料的佔位符，讓使用者感覺是立即回應，然後在回應成功後用真實資料替換虛擬資料。根據目前的探索結果，它的使用場景可以是類似編輯器的應用、系統設定模組以及一些更簡單的清單。
後來也加入了useForm、useAutoRequest、useSSE等請求策略模組，但這還遠遠不夠。
2023年5月13日，我在github上收到這樣的issue
一開始我並沒有太關注這個問題，只是簡單了解了openAPI自動生成請求碼的功能，覺得非常好，但是由於精力有限，並沒有深入思考那個時候我還沒有考慮alovajs的方向。但最近，我偶爾會思考alovajs的方向，這個仍然懸而未決的問題一直浮現在我的腦海中，然後悄悄地將這個問題的標籤從“feature-request”更改為“feature-request:confirmed” .
同時這個問題讓我體認到alovajs還可以拉近前端和後端的協作距離，進一步簡化前端開發工作流程。這是我為alovajs 3.0設定的開發方向：
alovajs將最大程度地幫助開發者簡化API整合工作流程，你只需要指定使用哪個API即可（這也是思考了3個月的結果）
我的具體計畫如下：
上圖中的步驟1、2、3、4、6是透過自動產生API程式碼來解決的，但是我們的生成計畫相比openapi-generator這樣的工具會走得更遠。會自動產生完整的ts類型，完整的描述請求函數，無論是js項目還是ts項目，都無需引入，讓開發者呼叫就像直接調用location.reload一樣方便，並且請求函數可以直接看到完整的描述和請求參數類型提示。
由於自動產生的請求函數有完整的描述和類型提示，vscode外掛程式完成了互動方式快速檢索所需API，不再需要查閱API文件。
解決前後端協作落差問題，介面任何變更都可以自動通知前端。如果專案建置過程中發現有變化，就會拋出錯誤並停止建置。如果是ts項目，編譯時也會拋出錯誤，也可以透過vscode外掛程式查看變更記錄
這裡是 vscode 擴充的示範影片。
如何解決第6步「寫複雜的請求邏輯」？當然是利用請求策略模組，它具有高效能、場景化的特點，使用者可以用極少量的程式碼實現各種場景請求功能。
2024年3月，制定了alova@3.0的開發計劃，花了4個月的時間與核心成員MeetinaXD重組了幾乎整個項目，並且有很多優化：
底層架構進行了重新設計，一組鉤子可以在 Vue、React、Svelte 甚至 Vue options 風格中同時使用。
可用範圍已增加到伺服器端。您可以在express、koa、nestjs等伺服器端框架中使用alova，並且新增了新的伺服器端請求原則伺服器鉤子。
alova@2.x 中的 10 個配置已棄用，並優化了 9 個設計。
另外，3.0最重要的部分，我們核心成員czlin負責的vscode插件也可用了，基本上達到了我們一開始設定的目標。
至此，alova@3.0已經過了內測期，可以在生產環境穩定使用了。
當時一篇被詬病的文章《是時候更換你的axios了》上了熱搜。
剛推出的時候確實沒有那麼好，但我知道每個產品都不是一蹴而就的，需要時間的沉澱。
Apple 1電腦一開始連外殼都沒有
Vue的發展歷程也是一個不斷探索、不斷進步的過程
我就是被這樣的產品之旅所感動，堅持做一件事是最容易成功的方法。好的產品都需要經過好幾年的考驗，更何況alovajs，它才出現了1.5年左右，也才被一些人接觸了8個月。這段期間，也一直在探索更好的解決方案，一步步向前。
alovajs 最初設計的 useHooks 包括 useRequest、useWatcher、useEffectWatcher、useManual、useController，後來逐漸減少到只有三個核心 hook：useRequest、useWatcher、useFetcher。
提交地址
並行請求的設計中，是實現類似Promise.all的形式，還是現在綁定onSuccess函數的形式，我糾結了好幾個版本，來回改了，下面是當年被遺棄的響應者的設計。
未找到提交記錄
為了相容於IndexedDB等非同步快取方案，我最初嘗試將儲存適配器設計為非同步功能，但會帶來一系列問題，然後嘗試透過StorageConnector實現事件機制，這還是不夠完善，最後到了目前自訂的localCache異步函數機制。
提交地址
也感謝支持alovajs並做出貢獻的朋友們。以下是幾張截圖，還有很多貢獻沒有收錄。
並不斷補充文件細節和完善最佳實踐，大膽嘗試快取恢復模式的快取版本計劃，並為了給alovajs提供完整的ts類型提示，嘗試使用自動類型推斷來減少開發者定義類型的麻煩，確實要花很多精力去優化、相容不同的UI框架等等
其中文件已經大改了兩到三次。感謝@Orange Peel提供了第一次文件修改意見，感謝@Well提供了第二次文件修改意見，我們的文件才有了這樣的聲譽。
@green tree 幫助我為 alova 開闢了新的想法。
很多事情已經不太清楚了，npmjs 上的記錄告訴我已經發布了 146 個版本。
github上也有很多人提出了Bug，我也第一時間回覆並修復了。我真的非常非常感激。如果我不能立即判斷問題，我也會在codesandbox上重現，並用這個demo作為與用戶溝通的橋樑。
非常感謝您的閱讀？ ，再困難，路還是要繼續。
如果您認識alovajs，請前往Github給它一個star。
如果你想了解alova，可以訪問官方網站，在這裡你可以找到更詳細的文件和範例程式碼，幫助你更好地理解和使用這個工具。
如果您有任何疑問，可以加入以下群聊進行諮詢，也可以在github倉庫中發表討論。如果您遇到問題，請在github issues中提交，我們將在最快的時間內解決。
也歡迎您貢獻自己的力量，請前往貢獻指南。
以上是開源月數：我如何維護下一代請求工具的詳細內容。更多資訊請關注PHP中文網其他相關文章！
