作為用戶的體驗的主場景，最希望的就是“觸之即達”，第一時間對各種操作有響應，web2.0帶來的大量loading或者骨架屏已經成為了當前用戶所厭惡的典型界面，特別是在剛剛明明進行了請求，重復操作時又會再次loading的場景中，前端開發者也在通過各種辦法提升相應界面展示性能。
<bdo id='pwg4y'></bdo><ul id='pwg4y'></ul>
試想一些場景：1. 對一個有翻頁的表格進行來回翻頁操作（第1頁-第2頁-第1頁），明明前面已經加載了第一頁，再翻回去的時候，大概率會加個loading再請求一次；2. 有一個排序列表，進行拖動排序，你會在哪里保存排序后的數據；3. 文章閱讀最后有個“點贊”操作，點了之后是立即顯示已贊，還是請求后顯示已贊？ 當看到這些問題時，你可以說我做了緩存，做了雙data數據延遲更新用來立即展示用戶操作。 OK，如果你做了這些步驟，那就已經引入了樂觀UI的處理范疇，在不同場景也會有很多不同的做法。既然這種做法很常見，那么作為最喜歡造輪子和概念的前端娛樂圈里，絕對不會放過這個機會，于是就有了這個概念 SWR （Stale-While-Revalidate）。
什么是 SWR？
SWR 是一種用于優化前端數據獲取和緩存的策略。一種由 HTTP RFC 5861 推廣的 HTTP 緩存失效策略。在設置的失效時間之內，它能夠立即返回緩存數據，讓頁面得到及時響應，并在緩存失效時回調更新數據驅動界面變化。
SWR 如何工作？
SWR 的工作流程相對簡單而有效。當你需要獲取某個數據時，SWR 首先檢查本地緩存是否存在相應的數據，并且檢查數據是否過期（Stale）。如果本地緩存的數據沒有過期，SWR 將立即返回緩存的數據給你。這樣做的好處是用戶立即獲得了先前的數據，不需要等待新數據加載。
與此同時，SWR 也會發起一個新的數據請求（Revalidate）。當數據請求完成后，SWR 將使用新數據更新本地緩存，并通過觸發狀態更新或回調通知你數據已經更新。這種機制確保了頁面上的數據保持最新，并且在等待新數據時也不會出現空白的內容。
SWR 的優勢和特點
-
提高用戶體驗：SWR 的快速緩存和平滑更新機制確保用戶立即獲得過去的數據，并在后臺獲取新數據，從而顯著提高用戶體驗。
-
減少網絡請求：通過有效利用緩存數據，SWR 減少了不必要的網絡請求，減輕了服務器和網絡的負擔，加快了頁面加載速度。
-
自動處理請求重復：SWR 在請求數據時處理了重復請求問題。如果有多個組件同時請求同一數據，SWR 會確保只有一個請求被發送，然后將響應結果分發給所有請求。
-
錯誤處理和重試：SWR 支持自定義錯誤處理和重試策略，允許開發人員靈活地處理網絡錯誤和失敗的情況。
-
輕量且易于集成：作為一個簡單的庫，SWR 的集成非常容易，幾乎可以在任何前端項目中使用，不僅限于 React。
需要注意的是，雖然 SWR 不是一個官方的標準，但它的設計和實現受到了一些前端性能優化的最佳實踐和原則的影響。這些原則包括減少網絡請求、提供優雅的降級策略、盡早展示數據等。因此，雖然 SWR 不是標準，但它體現了一些通用的前端開發原則，并且在實踐中已經被證明是一個有效的工具。
盡管 SWR 是一個功能強大且受歡迎的前端優化庫，但它也有一些潛在的缺點和限制。以下是一些 SWR 的缺點：
-
只適用于特定場景：SWR 主要用于優化前端數據獲取和緩存的場景，如果你的應用程序并不涉及頻繁的數據獲取和緩存，或者使用其他方法來處理數據，那么使用 SWR 可能沒有明顯的好處。
-
依賴服務器支持緩存控制：SWR 使用 HTTP 頭部中的緩存控制參數（如 max-age）來管理數據緩存，但這要求服務器正確配置緩存策略。如果服務器未正確設置緩存頭，SWR 的緩存效果可能會受到影響。
-
不適用于所有數據請求：SWR 最適合用于頻繁請求的數據，對于不太頻繁變化的數據，使用 SWR 可能會導致不必要的請求和數據傳輸，從而浪費網絡資源。
-
不支持文件上傳等操作：由于 SWR 旨在處理數據獲取和緩存，它不適用于文件上傳等需要特殊處理的操作。
-
可能導致數據不一致：由于 SWR 的數據更新是異步的，當快速頻繁地更新數據時，可能導致頁面上的數據不一致，需要開發者謹慎處理這種情況。
-
對于特定錯誤處理的限制：SWR 提供了一些錯誤處理的支持，但在某些特定的錯誤處理場景下，可能需要額外的定制和處理。
-
數據不一致性風險：如果 SWR 中使用的數據請求是不冪等（non-idempotent）的，可能會導致數據不一致性的風險。這需要開發者保證數據請求的冪等性。
