你好!
35 歲,從無相關經驗開始踏入 Web 工程師之路的人。
想像一下,你平常用手機看社群媒體時,按一下「按讚」畫面就能流暢更新,你會覺得這很理所當然吧?
如果每按一次「按讚」就整個畫面變成空白,然後又從頭重新讀取……光想像就讓人覺得很糟糕。
這次要用大家上班都能理解的「會議紙本資料」來比喻,清楚說明讓現今 Web 應用能順暢運作的技術——「SPA(單頁應用程式)」。簡單又一目瞭然!
本篇文章適合這些人
簡單比喻就是:
・傳統型 Web 應用
「為了修正一個字,整份會議資料『每人一本、所有頁面』都重新印刷的低效率公司」
・SPA
「只有修正的地方,立刻貼上便利貼覆寫的智慧公司」
就是這麼簡單!接下來我們一步步說明這句話到底代表什麼。
傳統網站大致上有兩個讓人覺得吃力的地方。
一句話:即便只想改變頁面的一部分(例如「按讚數」),也得把整個畫面從頭重新載入。
具體例子:
在會議室看資料時,突然發現「第 10 頁的銷售數字少了一位!」。傳統的網站行為就像是:「很抱歉!請大家把手上的資料收回,我們會重新印一次再發給各位!」資料被收走、手邊什麼都沒有(會議中斷)的那段時間,就是「畫面變成空白」的原因。
一句話:伺服器(負責製作資料的行政部)每次都必須從頭印出「HTML(封面)」「CSS(版面)」「資料(內容)」全部的頁面。
具體例子:
就只是改一個字,卻要消耗全頁的紙張和墨水來印。照這樣下去,行政部(伺服器)和複合機都會被搞垮。
解決「每次都要重新印全部頁面」問題的,就是
單頁應用程式(SPA:Single Page Application)。
顧名思義,SPA 是在「維持同一個頁面(手上那份會議資料)」的情況下,只更新必要的部分。
SPA 能做到這件事的重點有兩個:
1. Fetch API(在會議不中斷時,暗中跑去確認數字的年輕同事)
2. DOM 操作(在對應位置貼上便利貼進行覆寫)
換句話說,就是「會議繼續進行的同時,年輕同事暗中去拿正確數字,然後在你手邊的資料上迅速貼上便利貼修正」。
下面看支撐「暗中只拿數字回來」這個機制的三項技術,懂了這些你就差不多掌握重點了。
一句話:
在不讓畫面卡死的情況下,會在背景向伺服器取資料的功能(也就是「非同步通信」)。
具體例子:
發現錯字時,不用停掉會議,偷偷請 Fetch 小哥去問會計正確數字。Fetch 小哥在後台跑的同時,你可以繼續討論其他頁面內容。(=畫面不會凍住,還能繼續操作!)
一句話:
對於通信(年輕同事跑腿)的「結果」,事先預先安排好後續要做的事情的寫法。
具體例子:
叫 Fetch 小哥去跑腿時,事先告訴他「拿到後要怎麼做(用 Promise)」。例如:「拿到正確數字就(then)把它寫在便利貼上並貼上去;如果會計不在(catch),就回報給我」,這樣就是預先設定好未來的行動規則。
// 使用 Promise 的「後續安排」範例
fetch('https://api.example.com/sales-data') // ① Fetch 小哥,去問會計數字!
.then(response => response.json()) // ② 將會計的回覆整理成便利貼上的內容!
.then(data => console.log('要修正囉!', data)) // ③ 把便利貼貼到手邊的資料上!
.catch(error => console.error('會計不在!', error)); // ④ 失敗就回報!
一句話:
伺服器(會計部)與前端交換必需資料時,使用的簡潔格式,只傳需要的內容。
具體例子:
如果會計給回來的是一本有封面的厚報告(HTML),Fetch 小哥要搬回來會很慢。因此 SPA 常用像 { "sales": "5,000,000", "rate": "120%" } 這種只包含必要資訊的便利貼(JSON)。這樣 Fetch 小哥搬得快,拿到的人也能馬上貼上使用。
辛苦了!把本篇重點整理成三項:
1. 傳統型:每次更新都要「重新印整份資料」,簡單但每次更新代價高
2. SPA:在背景只取得資料,並只更新必要部分
3. 常用技術:Promise(非同步處理的管理)與 JSON(資料格式)
把「會議的紙本資料」這個比喻放在腦中,遇到「非同步通信」或「JSON」等名詞時會比較好想像。
我自己也還在學習中,希望能把理解一點一滴累積起來。
那麼,下次文章見!