前言
當我們拿到一份完整的設計稿後，如果我們選擇先讓前端開工，而你的後端可能因為各種原因並沒有辦法先產出 API，此時我們會選擇製作「假資料」先讓畫面有個基本可操作的流程和視覺，不論是為了 demo 給內部的團隊人員看或是給客戶，他們可能只注重在「畫面的呈現」上，可是以開發者的角度來看，讓這包假資料在未來能和後端開出來的資料架構相近，會是我們最理想的狀況，那麼等到後端開出 API 時，前端也能更快速地把 API 接上，同時不需要消耗前端太多的時間，但現實真的這麼理想嗎？
如果後端使用的是 graphql，也更能預見前端必須要處理 loading, fetch more, network status, update cache... 等等的問題，那麼如果前端此時只是做出一份假資料（.json 之類），然後將它注入到畫面上，一切看起來都很美好，但當要接 API 的時候，就會發現根本是一團糟（後面會分享實例）。
所以本篇想分享自己這幾年來在專案上製作假資料的心得，以及架構要如何事先規劃，以下會先針對各種可能碰到的狀況做分享，結尾也會附上近期發現的 API mocking library。
理想中的理想：（下列狀況都不在本篇討論範圍內）
- 後端會先開好 API
- 你們會寫對接 API (規格)文件
所以我們目前假設的情境就是「沒有 API 也不會有文件」的狀況下：
狀況1: 前端完全不懂後端會怎麼開 API (資料層的重要性)
假設我們有一筆節目的資料，他有標題、起迄日期、地點三種資料要呈現，顯示日期時又要求以「/」符號作為分隔線，可能會出現以下這種假資料
或是這種
我想有些經驗的前端，應該都能理解下面這種格式比較常見吧。但上面這種格式我也看過不少前端這麼寫，當然你的後端如果會把資料一欄一欄拆開來丟給前端，同時又會幫你把格式處理好，那我也服了。
理論上依我假設的情境，「節目」應該會是一包 object，底下描述了該節目的資訊，同時地點隸屬於節目之下，所以資料的關係不會是在同一層級上才對。
那麼如果前端一開始是用上面那種方式來做出畫面，當然該有的資訊他都有做了，但仔細一看會發現幾點問題：
- 資料的巢狀結構關係
- 日期的格式
這兩個問題，如果我們有做好資料層的預處理，那還算方便 (如下)
但通常來說，會開出這樣架構的前端，也不會想到這層預處理層(通常...)，而且欄位名稱如果取得太奇怪，也會讓人很困惑到底該如何對應 API 給的資料，再加上我舉的例子非常簡單，實際資料可能還會需要做很多狀態的判斷，以致要接 API 時，總是會需要去改動到我們原本已經做好的 View 層，那麼就會讓開發的時程被拉長，中間可能也做了很多白工。
狀況2: 沒有事先處理可能的狀況
任何 request 合理來說都該處理 loading, error 而列表類的又要多處理 pagination，其實在假資料階段時很容易忽略這些事情，但因為我們的期望是未來要接上真資料時，可以以最小的改動，不必理解 view 層也能快速完成，所以在這個階段如果以「模擬真實情況」的目標來做，是否就能省下後續回頭研究 code 的時間呢，看下面範例：
p.s. 資料的來源情境為：有一堆會被隨機推薦的項目，可能有不同類別，API 會是 union type 的情況
目前我照著這方式，確實幫自己省下了不少時間，等到後端要開 API 時，就能很快速地找到資料層，並且只需要抽換資料的來源(useMockQuery & dataMiddleware)，其他的部分我都不必再多做處理。
剩下最麻煩的，大概就是建假資料本身了吧…。
最後附上一段「沒有預先處理其他狀況」的程式碼範例給大家參考，或許會對本篇想表達的重點更有感
上面這段程式碼，單看畫面的部分其實都是一樣的，重要的差別只在於各種情境的預處理，review code 時或許不會想到這些點。
「等到要接 API 時再來處理就好啦」
「好煩哦，先讓畫面能看能動就好，這樣客戶那就過了」
你以為未來的自己會有很多的時間來改，但現實總是殘酷的…
為了盡量避免那些充滿不確定性的東西，導致未來的自己陷入無限加班與後悔的輪迴之中，還是推薦能先處理掉的就先處理掉吧！
文末推薦一個 API mocking library “msw”，主要它支援 REST / Graphql API 兩種方式都有，近期或許會來嘗試玩玩看它！
