積沙成塔，滴水穿石

 今天在看code 的時候，看到了寫法很有趣 Object.freeze() ，凍結—可以凍結對象。 (題外話...讓我想到一首歌「林俊傑-凍結」.... 凍結那時間 凍結初遇那一天 ) 🧊🧊  功能 和 const 很像 與防止修改有關。 於是就查一下AI 給的回應(圖1)： Object.freeze 與 const 差異(圖1) 註解 當使用  const  聲明一個變量時，這個變量的引用不能改變，但如果這個變量是對象，對象的屬性仍然可以被修改。 換句話說也就是 設定成object 裡面的屬性值也一樣可變。 實驗 有做了幾次實作發現到  Object.freeze 只能淺凍結  (圖2)，除非就是全部凍結。 Object.freeze 凍結(圖2) 換句話當 object 內的物件也想要 凍結， 那麼 就也要下 Object.freeze(obj1.Hello) 。(圖3) Object.freeze 凍結裡面(圖3) 心得 freeze 凍結，再給予其他參數 是不會拋出TypeError，但是 const 會顯示錯誤。 剛開始看到freeze 想說這不是和const 差不多嗎?  一樣都是不可修改。一開始以為freeze 是凍結就不可修改， 結果 測試下來 和const 一樣， 在特殊情況下 也能 改變其對象的值。 以 結冰的湖水 來比喻 freeze， 只是冷凍了 表層，其內還是活水，除非 下層 也 結凍。 可以參考 深層結凍  deepfreeze , 利用 迴圈方式做凍結。 題外話 如果要宣告object 不可被擴充，要能更改 裡面物件屬性值，其實也可使用 Object.seal 至少他不會拋出TypeError😝

串接API時遇到個問題，對方的api時竟然逾時了..... 一分多鐘，檢查後發現是對方API出了些問題，導致POST 過去後 一直得不到回應。 導致前台畫面一直停在空白.... 這時就可以用個很好用的工具， Promise.race 簡單來說 就是 看誰跑得快，就回傳哪個值。 假設: 設定基本回傳時間 是5秒 ，但實際回傳 是8秒， 那麼會以5秒這個做為結束標準。 promise.race 設定 在無法確定對方API是否健康下，需要加入逾時設定。 這樣加入後，回應狀況好很多了。至少不會一直轉圈圈，陷入無限等待.... 讓我想到一首歌：圈圈圓圓圈圈....圈圈圓圓圈圈....

 上回提到用 IntersectionObserver 的方式來實現無限滾軸，當觀察目標 進入到畫面 就新增20筆。 這次的作法，則換成 只要滾軸 到達了底部 就做載入(圖1)；不再是 監測某個元素，是否出現在螢幕畫面。 滾軸到了底部更新(圖1) 這次的做法比較簡單，直接監測滾軸(圖2)是否已經滾到底部了，如果有滾到底部 再去做更新內容。(圖3) 監測滾軸(圖2) 監測滾軸是否滾到底部(圖3) 心得 IntersectionObserver 做的無限更新，在實作後加上查詢功能，會遇到個問題。原本的監測元素A會受到影響查詢功能，監測到的項目有可能不再 或不是原本的項目，則需要在重新綁定，否則有可能出現 滾軸無法動。 因為查詢產生出來的已經不是原本的tr 內容。 換句話說，只要IntersectionObserver 監測的內容有改變，就需要重新綁定監測。 ------------------------------------------------------- 用監測scrollbar 來做無限更新，就不會遇到這個問題。因為scrollbar 重頭到尾並沒改變內容，只有改變長度。 加上查詢後， 長度則可能停留在查詢前 ，則需要重新。 ex 在查詢前，長度在 500px； 查詢後項目 只顯示 2項，總高度 110px，但因為採用無限更新，滾軸 並不會重新渲染，所以就必須 將滾軸 scrollTo。 這兩者差異並不算太大，作法上的不同： 一個要重新綁定，一個要將滾軸 重置。

前情提要 最近的專案被要求要做到無限滾軸，有點類似像 看漫畫那樣，可以一直往下滾。 也有不少購物網站有做這樣的效果，ex: 掏寶、蝦皮。 IntersectionObserver  就可以做到這樣的效果，lazyload 延遲加載.... 在做大量圖片顯示的時候 就可以避免一次有太多頁出現。(圖1) IntersectionObserver 觀念 (圖1) 有不少做法是抓最後2行，再去更新；我自己的做法是在滾軸區域範圍設定一個底線，當滾到底線，再去更新達到的效果也是一樣的。 (圖2) 設定滾軸範圍的底線(圖2) 透過observer 去觀察 滾軸頁面滾到了#lastone ，如果滾到了 就加載 後面的資料。(圖3) 設立觸發時機(圖3) 之前有設立過觀察最後倒數第一行，但有時候螢幕大，連滾都不用滾，就自動加載完了😅 所以這次就換另外一種作法，設定底線 當滾軸 真的有滾到底線的邊頁#lastone 才加載。 無限滾軸demo(圖4)

前情提要 以前在寫api的時候，幾乎都是分開寫，各別檔案再寫的時候分開寫各自的API，但時隔3個月再回來看的時候，會忘記自己哪個API 寫了什麼，在做管理的時候比較麻煩。 有的時候，打包出來的檔案會因為佈署到不同環境而更改 API的位置。 例如: A電腦 192.168.0.123、B電腦 10.1.207.xx、C 電腦 211.207.0.1xx  當有寫API 的時候， 集中管理就派上很大的用場。(圖1) API集中管理(圖1) 有了集中管理，在更換API的時候就會比較方便.... 但如果佈署的主機越多，也是需要一個文件來做環境的管理。 遇到的問題 每次佈署環境，API就要再換一次... 因為總不可能 每次換個環境 就還要時刻更改api 網址。 解決問題 查了一下官網，發現有個.env 可以寫整個管理配置 。 就像是寫yml一樣，把所有參數都寫一塊，方便整理。 (圖2) .env 配置 (圖2) 需要的時候 在引用就可以了  (圖3) 引用.env (圖3) -------------------------------------------------------------------------------------- 心得 會這樣子提出來寫，是因為在佈署會時常需要變更環境。所以在打包的時候，就能一鍵切換環境，也不需要打開api.js 去更改，而是直接.env 再進行打包就可以了(圖4、圖5、圖6) .env 配置 (圖4) package.json (圖5) svelte.config.js (圖6) --------------------------------------------- 延伸閱讀 .env環境配置

前情提要 這次在專案上使用了sveltekit 作為前端框架，UI則是用bootstrap， 在列表頁的時候需要每5秒更新(圖1)，取得最新的生理資訊。 列表頁 (圖1) 但每5秒去得取api，其實是很耗資源的。尤其是長時間停留在頁面。(圖2) Network背景資源(圖2) 主想法 為了減少資源耗損，當按下「檢視」打開彈窗(modal)的時候，背景更新可以先暫時，畢竟彈窗(modal)會佔據整個版面，focus都會在彈窗上，等彈窗(modal)關閉後 再繼續執行背景更新。(圖3) 彈窗開啟(圖3) 實際作法 如果要觀測彈窗(modal)，就會需要動態監測dom的變化(圖4) ， 需要觀察 modal-open，是否有開啟。 動態監測dom(圖4)    在做法上使用了 MutationObserver 來監視dom的變化，當監測到 body 的class 出現了.modal-open，代表彈窗已開啟，就可停止背景更新。 (圖5) MutationObserver監視.modal-open(圖5) 遇到的坑 照著 MutationObserver監視.modal-open 來做背景更新的開關控管是成功了，但卻也延伸了其他問題— —「 切換到其他頁背景更新並不會停止」 。  切換到了B頁→A頁，B的背景更新並不會停止；從A頁 → C頁 ，A頁的背景更新並不會停止(圖6) ，也就表示 背景更新不會隨著切換頁面而停止。 主要是因為在同一個SPA的特性，頁面不重載，DOM並沒有銷毀。 SPA的特性，頁面不重載(圖6) 填坑--解決方法 加入了writeable 動態的背景更新「開關管理」，更新writeable的狀態，搭配 $  動態的讀取資料狀態的變化，類似redux的狀態管理 。因為用的modal在每頁都是相同的，並不會因為切換頁面造成dom重新渲染，所以監測也並不會因為切換頁而消失。 設立了一個 $modalObserver='' ，當彈窗(modal)開啟才給值  $modalObserver=0， 關閉 $modalObserver=1 $modalObserver 就可讀取到到最新的modal狀態，進而去執行該頁的背景更新，也就能避免累加的背景更新。(圖7) 當在A頁開啟modal的時候，就執行A頁的背景更新；當在...

發生情境 這次做了個搜尋鍵，點下後會執行一次API，進行搜尋。 可如果還沒搜尋完，就不斷的按下搜尋鍵，API就會不斷地執行 解決方法 1.  使用promise 使用promise，promise可以取得到pending 狀態。 而 await 則是一開始就進入到了等待的狀態。 透過 promise 在等待的期間，可以先將 按鈕的disabled = true，停止按鈕可點擊。 無論成功或失敗再將按鈕調回disabled = false function FindSearch() { document.getElementById("searchbtn").disabled = true; //停止按鈕 let chkEmpty = Object.values(searchWord).every(value => value === ""); if (!chkEmpty) { getPageList(searchWord) .then(pageList => { // 處理獲取到的頁面列表 console.log(pageList); }) .catch(error => { // 處理錯誤 console.error(error); }) .finally(() => { // 無論成功或失敗都要執行的操作 document.getElementById("searchbtn").disabled = false; //恢復按鈕 }); } } 2.   使用debounce debounce 防抖，狂點按鈕的時候，並不會連續執行，會超過一段時間後再觸發。 當搜尋框內打入文字超過一定的時間，此時才會去執行觸發 API，不會每打一個就執行 。 js ------------------------------------ 這兩者都能做到防止連續觸發。 在使用上如果真的要做到等待執行完成，才可以執行下次搜尋 使用promise 會比較好，可以對每個狀態去做主動處理，再按下按鈕的時候 就先暫停按鈕...