上個月收到鐵人賽的活動訊息立刻回想起去年在頒獎典禮羨慕著上台領獎的大大們，當下就決定來年一定要復仇，想不到時光飛逝一轉眼就到了復仇的時刻，但不知何時早已放下復仇的心，只有一週又一週的按照自己的節奏寫出每個禮拜想學的東西，算一算從去年結束鐵人賽後到今天剛好是第 40 篇，已經超過我過去五年寫過的文章數量了。
我想鐵人賽帶給我最大的收穫莫過於培養出固定的寫作習慣，是否得獎已經不是重點，雖然還是很想站上頒獎台風光一下，但我更喜歡每個禮拜為了寫出文章而必須去學習新東西的興奮感，同時間我也一直在尋找可以寫出長篇系列並且能實際轉換成產出的文章主題。
之前本打算鑽研區塊編輯器開發，研究了幾個月後覺得一直無法說服自己持續投入，除了技術上的門檻外，主要原因還是因為案子接了這麼多年從來沒客戶請我開發 Block，反倒是我主動去跟客戶建議說可以把某些功能做成 Block，區塊編輯器很優秀，只是市場上有太多已經非常成熟的替代方案可以選擇，現階段並非客戶急需迫切解決的問題。
至於什麼問題才是 WordPress 站長們的痛點呢？說真的，痛點多到用一篇文章應該還列不完，但從我接觸的案件中電商的痛點絕對是大宗，畢竟跟錢有關的會特別痛，尤其是 WooCommerce 的結帳流程，太常被問到像是如何增加台灣縣市下拉選單、選擇超商時隱藏地址欄位、選完超商取貨結帳資訊會不見等等一堆問題。
其次是效能瓶頸，WooCommerce 累積了許多早年的程式碼，當商品或是訂單數量一多，如果主機不夠力又沒快取就能在前後台明顯感受到載入速度的遲緩。效能以及購物流程的問題我覺得才是對於使用 WordPress 經營電商平台最大的痛點，不然有這麼巨量的佈景主題跟外掛可以使用絕對是完勝任何一家開店平台。
Snipcart 的啟發
當然 WordPress 生態系不只有 WooCommerce 一套購物車外掛，但以台灣金物流的支援度來說 WooCommerce 絕對是首選，然而如果要使用靜態化主機來提升效能的話目前還沒有一家廠商可以支援 WooCommerce，詢問客服後他推薦使用 Snipcart 這一類的第三方購物車服務來加入購物功能。
於是好奇去玩了一下 Snipcart，想不到玩了之後驚為天人，不用跳轉畫面的結帳超流暢：
看了之後就在心中埋下一顆種子，幻想哪一天 WooCommerce 也能用這樣的介面來結帳不就帥炸了！！！雖然應該有現成外掛可以組合成這樣的結帳流程，但能原生支援的話對站長來說應該會更方便，再搭配適合台灣電商的使用情境，深深覺得這樣的方向應該很有搞頭。
由於這樣的使用流程完全是以 API 來驅動，拜 WooCommerce Block 所賜，讓開發者可以做到用 Store API 來呈現商品列表、加入購物車、送出結帳資訊等行為，而且在 WooCommerce 6.4 版後就內建了這個 API，萬事俱備，今年給自己的鐵人挑戰決定就是 WooCommerce Store API 啦！
WooCommerce Cat 外掛
剛剛逼正妹助理在三秒內給我一個音節的英文單字，因此這個外掛就叫 WooCommerce Cat 吧XD，剛好非常符合這支外掛想要表達的精神：讓 WooCommerce 可以變得跟貓咪一樣輕盈～
我預計會有以下的功能：
- 身為顧客，我可以瀏覽商品列表並將商品加入購物車
- 身為顧客，我可以瀏覽商品頁面選擇規格後加入購物車
- 身為顧客x，當商品加入購物車時我可以看到側邊欄顯示購物車內容
- 身為顧客，我可以修改購物車的內容
- 身為顧客，我可以使用折價券折抵購物車金額
- 身為顧客，我可以在點選結帳後前往金流商頁面進行付款
- 身為管理員，我可以使用短碼設定商品列表頁、購物車以及結帳頁
上面寫的好像都是廢話XD，但也沒辦法，要用手刻的話這些功能都要自己來了，技術的部分我會採用兩個框架，第一個是 Alpine.js，與三大 JS 框架相比它非常輕量化，整個體積不超過 50KB，重點是可以直接 CDN 引入，不用搞煩人的編譯環境。
Alpine.js 的語法比較接近我熟悉的 Vue.js，再加上最近專案用了很多，本想挑戰用 React 開發，但以掌控度而言還是先以自己熟悉的比較好上手。CSS 的部分我會採用台灣之光 Master CSS，直覺的語法更勝 TailwindCSS，再加上容量也是小到不行，要寫出精簡的 CSS 不能沒有它。
可能會有的問題
由於 WooCommerce Store API 是以 Cookie 來紀錄顧客的結帳資訊，因此會員註冊登入不在它的防守範圍，而 WC REST API 也沒有提供會員相關的功能，這部分只能靠自己處理了，還好之前很常弄不會太難搞，但就變成還要刻登入表單了…恩，先假裝沒看到XD
其次是安全性的問題，Store API 應該有做基本的防護，像是避免使用者在前端透過開發者工具修改結帳金額，或是設定參數的上限避免被惡搞，根據官方部落格的回覆，因為 Store API 是使用 WooCommerce Block 必要的工具，因此預設是開啟的，萬一哪天你的後台多了很多垃圾訂單我想也不用太意外…
預計進度
第一週
實際測試 Store API 的所有路由，確保回傳資料的內容，清查不足的部分還需要自行設計哪些 API
第二～三週
完成前端畫面，包含商品列表頁、商品頁、購物車以及結帳頁
第四～五週
開始 WooCommerce Store API 串接，並進行測試與除錯
在開發過程中如果你有什麼好建議也歡迎留言與我分享！天氣熱很適合在家閉關寫文章，來拼一下！
