什麼時候寫deep這個問題 困擾了我很久。這次深度解析下： 需要 deep: true 的情況 // 情況1：直接監聽一個 ref/reactive 對象，且可能只修改內部屬性 const obj = ref({ a: { b: 1 } }) watch(obj, callback) // 不會觸發 obj.value.a.b = 2 // 修改內部屬性 watch(obj, ca
兩種方案 1、數組打平，根據搜索字符在打平數組裏去filter出滿足條件的node節點，但此時被篩選的節點只有子節點，然後再通過被篩選出的子節點去找對應的父節點，然後拿到結果後轉成tree結構 優點：思路簡單，打平數組用了遞歸，好理解 缺點：找父節點的時候相對麻煩。 2、寫一個遞歸算法，滿足條件就返回tree 比如有一個簡單個tree const treeData = [ {
在你的 axios 封裝文件中，你需要兩個外部變量來管理狀態： // 標記是否正在刷新 token 的“鎖” let isRefreshing = false; // 存儲因 token 失效而掛起的請求的“隊列” let requestQueue = []; 請求攔截器 (Request Interceptor) 它的任務很簡單：在每個請求發出去之前，都帶上當前的 token
我們都曾經歷過這樣的下午：一個看似邏輯嚴密的模塊，在實際運行時卻表現得像個失控的野獸。我的故事，就從一個本應“智能”處理登錄和 Token 刷新的 ajax 請求封裝函數開始。 我希望它能在接口返回 400（需要登錄）或 4_01（Token 失效）時，自動完成登錄或刷新 Token，然後再重新發起剛才失敗的請求。然而，它卻在某些情況下陷入了可怕的無限循環，瘋狂轟炸着我的服務器。 起初
如題：如何用useRef優化重複請求。 寫業務代碼，時而會遇見這種情況，如下偽代碼： useEffect(() = { // api請求 () }, [a, b]) 參數a來源某接口請求、參數b來源另外一個接口請求 毫無疑問，上面寫法回調函數一定會進去兩次，除了用參數校驗 比如滿足條件再進入api調用，還可以用useRef來暫存參數，而又不會引起頁面的re-rende
水平垂直居中是面試常考的環節 今天就一步一步分析下是怎麼做到的，以前呢多少有點死記硬背的感覺，沒真正去梳理過。 先看看整個實現的流程圖片吧。 1、當left：50%如圖1 2、當top:50% 如圖2 3、要想呈現如圖3的情況，有兩種實現方案 （1）方案1 在已知目標對象寬高的情況下，可以通過設置margin-left:-寬/2 margin-top:-
先看一段代碼： console.log('-',new Date().getTime()) for(let i = 0;i100;i++){ setTimeout(function(){ console.log('exeute'); },100); } console.log('i',new Date().getTim
大致問題是： 通過map或者foreach循環的回調函數操作數組，回調函數內部有ajax異步函數，通過await同步的寫法來調用的。console.log打印出數組跟實際渲染到view層的頁面始終不一致。 後來改寫成for循環就好了。 所以總結出來，基礎知識，在理解map和foreach這個api不夠深刻，也對await 關鍵詞的使用場景理解不透徹（雖然是for循環，但作用域函數可以找
