MUKI space*
Front-end Development,
Effective Note-Taking.
使用 indexedDB Web API 製作預存後端 API 資料的功能
使用 indexedDB Web API 可以有效地在瀏覽器端預存後端 API 資料，從而減少 API 呼叫次數，提高使用者的讀取速度，並支持離線資料訪問。資料結構設計上，使用 rId 和日期範圍作為索引，以便精確檢索。核心功能包括初始化資料庫、清除資料庫、存入及取得快取資料，以及處理資料限制。這些功能能提升系統效能、降低伺服器負擔，並提供離線支持。
然而，使用 indexedDB 也有一些缺點，如增加管理複雜性、儲存限制和資料一致性問題。為解決這些問題，可能需要實作資料過期機制或使用版本號判斷資料新舊。此外，選擇 idb 套件可以簡化開發過程，提高效率。總結來說，indexedDB 提供了一個靈活的數據存儲解決方案，但需根據專案需求和資料正確性進行謹慎評估和實施。...
動態渲染 Vue 元件以及動態導入模組，簡化重複邏輯
在開發模組化功能時，使用大量的 v-if 來動態渲染 Vue 元件會導致程式碼重複且難以維護。為了解決這個問題，可以透過動態渲染元件和動態導入模組來簡化邏輯。首先，使用 Barrel Files 將模組集中管理，接著在 App.vue 中根據 moduleId 渲染對應的 Vue 元件，避免用大量的 v-if 判斷。進一步優化可以使用 Vue 的 動態元件搭配 Mapping 表格來渲染模組，這樣可以大幅減少重複的程式碼。
為了進一步簡化，推薦使用 Vite 的 import.meta.glob 功能，這樣可以自動批量導入模組，無需手動更新 Mapping 表格或 index.ts 檔案。透過這種方式，不僅程式碼更簡潔，未來新增或修改元件時只需將新檔案放入目錄即可，無需更改現有邏輯，讓開發和維護更加高效。這種動態渲染方式特別適合需要處理大量條件邏輯的場景。...
用 Geolocation API 和 Leaflet Routing Machine 實作叫車導航功能
使用 Geolocation API 和 Leaflet Routing Machine 可以實現叫車導航功能。Geolocation API 提供使用者的經緯度，而 Leaflet 是輕量級地圖工具，用於顯示地圖和標記。Leaflet Routing Machine 則專門用於路線規劃和導航，能計算兩點間的路徑，並提供距離和時間資訊。這些工具的結合可實現從位置追蹤到路線導航的完整流程，適用於叫車服務中，Geolocation API 提供即時位置，Leaflet 負責地圖呈現，Leaflet Routing Machine 負責路線計算與導航視覺化。
在實作中，使用者輸入地址後，系統會自動計算司機的路線並顯示在地圖上，預估距離和時間。模擬啟動後，司機標記沿路線移動，顯示即時距離。此功能不僅適用於叫車服務，也適合物流追蹤、旅遊規劃和遊戲開發。完整程式碼可參考範例連結，並可深入了解 Leaflet 和 Routing Machine 的其他功能。...
用 Geolocation API 取得與追蹤使用者地理位置
Geolocation API 是 HTML5 Web API 中一個強大的工具，允許網頁存取使用者的地理位置，能提供導航、在地服務等功能。此 API 注重隱私，只有在使用者授權的前提下才能取得位置資訊。Geolocation API 的核心功能包括取得使用者目前位置、持續監控位置變化及提供位置精準度資訊。瀏覽器可透過 GPS、網路位置及 IP 位址來確定使用者位置。
使用 Geolocation API 前需檢查瀏覽器支援性，並透過 `getCurrentPosition()` 方法取得當前位置。此方法接受三個參數：成功回調、錯誤回調及選項設定。為了即時追蹤位置變化，可使用 `watchPosition()` 方法，並結合地圖服務如 OpenStreetMap 來顯示位置。若使用者拒絕授權，需引導其修改瀏覽器設定以重新啟用地理位置功能。此 API 提供的功能強大且安全，但需經過使用者同意以保護隱私。...
使用 Barrel Files 的好處與大多數人不推薦的原因
Barrel Files 是一種用於簡化模組匯入的技術，通過匯總其他模組，讓程式碼更簡潔易於管理。使用 Barrel Files 可以有效管理模組，提升程式碼的可維護性，並且可以隱藏內部實作的細節。然而，Barrel Files 也存在一些缺點，如可能導致循環引用問題，影響 Tree Shaking 的效果，並使依賴關係變得模糊，進而影響性能和測試的隔離性。
是否應該使用 Barrel Files 是一個有爭議的問題。有些開發者喜歡其結構化優勢，而另一些人則擔心其可能拖慢網站速度並增加測試難度。在考慮使用 Barrel Files 時，需要根據專案的規模和模組之間的依賴關係來做出最佳選擇。總之，Barrel Files 可以簡化匯入匯出，但並非萬能，需謹慎評估後再決定是否採用。...
使用 ts-rest 與 Zod 定義 API 合約和進行資料驗證
本文介紹如何使用 ts-rest 與 Zod 來建立型別安全的 API 合約及進行資料驗證。 ts-rest 是一個專為 TypeScript 設計的工具，能夠幫助開發者輕鬆定義和管理 API 合約，確保前後端的一致性。 Zod 則是一個資料驗證套件，能在執行階段驗證資料的完整性和正確性。文章提供了一個完整的前後端範例，後端使用 Node.js 搭配 Express 框架，前端使用 React.js，並詳細介紹了如何定義 API 路由和使用 Zod 驗證資料。
文章中描述的開發步驟包括：首先使用 ts-rest 定義 API 合約，確保每個 API 路由都有明確的類型定義；接著使用 Zod 驗證資料結構，確保符合預期格式。後端部分，使用 Express 框架建立 API 路由，並透過 ts-rest 將 API 合約與 Express Server 連接，實現資料處理的邏輯。前端則透過 ts-rest 呼叫後端 API，並展示如何在 React 中實作這些功能。文章最後提供了 CodeSandbox 的程式碼範例，供讀者進一步探索和測...
什麼是 ts-rest？論 TypeScript Interface 的局限性與前後端導入 ts-rest 的優缺點
在前後端開發中，使用 TypeScript Interface 來定義 API 型別存在一些局限性，如前後端型別不一致和型別驗證不嚴謹等問題。這些問題在專案變得複雜時尤其明顯，因為 API 回應資料來自外部服務，無法保證每次都符合定義的型別。為了解決這些問題，ts-rest 提供了一種自動化的型別同步工具，能夠在前後端之間自動同步 API 型別，並結合 Zod 進行動態驗證，確保資料完整性。
然而，ts-rest 的最佳使用方式是前後端共同導入，這在台灣的產業生態中並不容易實現。即便如此，前端單獨導入 ts-rest 仍能透過 Zod 提供的型別驗證機制，減少錯誤發生的機率，相較於手動建立 TypeScript Interface，ts-rest 能夠提供更強大的型別檢查與資料驗證，特別適合大型或 API 變動頻繁的專案。儘管如此，對於小型或型別驗證需求不高的專案，手動建立 TypeScript Interface 仍然是一個合理的選擇...
初探 Singleton Pattern 設計模式
最近在學習 JavaScript 設計模式時，發現自己常用 Singleton Pattern，但未深入理解。設計模式是可重複使用的解決方案，像數學公式一樣，能提高程式碼的可讀性與開發效率。設計模式分為建立型、結構型與行為型。
Singleton Pattern 屬於建立型設計模式，確保類別只有一個實例，避免資源浪費，適合用於全域狀態與共享資料管理。然而，過度使用可能導致狀態難以管理與測試困難。選擇是否使用 Singleton 需視具體需求而定。...
使用 Element Plus 分頁處理前端的大量資料，並使用工廠函式優化程式碼
通常在網站上顯示大量資料，前端會從後端 API 獲取分頁資料，但若後端未提供分頁功能，可使用 Vue3 與 Element Plus 實現前端分頁。Element Plus 的 el-table 和 el-pagination 元件需自行處理。
利用工廠函式 (Factory Function) 可優化重複的分頁功能。工廠函式可接收參數並返回需要的資料，減少重複程式碼。透過工廠函式建立分頁狀態、處理資料過濾及跳頁功能，達到重用與減少冗餘程式碼的目的。...