LiveView 跟前幾篇用的 Controller View Template 有什麼不一樣

我們先來回顧一下 傳統的 Controller View 套路

1. 瀏覽器送出要求，如 GET /posts
2. Router 接到要求送到 PostController 的 index 方法
3. 把要求的項目套進 View 與 Template 回復給瀏覽器
4. 回覆給瀏覽器後結束

要注意的是
每次一來一回後處理這次連線的 process 就結束了，下一次就是全新的連線，
所以我在 /posts 看完所有的文章標題，想要點進去其中一篇文章，我就要再發一次全新的連線來要求 /posts/2 ，
Phoenix 就依照 id 為 2 的 post 來顯示單個文章畫面。
兩次要求是分開的事件，也就是兩次都是重新傳整個網頁，兩個頁面重複的東西像是選單也是要重新傳一次，
這樣的好處是架構單純，也是以前流行的做法。

所以 LiveView 是怎樣

在我們開始做 LiveView 之前最好先理解大概的原理，比較知道在幹嘛
簡單來說，開啟 LiveView 頁面時，瀏覽器與 Phoenix 會建立一個持續的 websocket 連結，瀏覽器頁面會自動依照伺服器上面的狀態來改變顯示的樣子

依照順序他做的事情是：

1. 瀏覽器送出要求，如 /live_posts
2. Router 接到要求送到 PostLiveView.Index
3. PostLiveView.Index 依照要求回傳出這次要有的網頁（這邊還跟上面很像）
4. 瀏覽器端 LiveView 頁面與伺服器建立 websocket 連結後，便開始等待伺服器端來的更改要求
5. 不管是瀏覽器端發起的事件，如按按鈕送出訂單，或是伺服器端的事件，如時間到搶購結束，都是統一去改變伺服器端的狀態
6. 只要狀態有改變，Phoenix 就會計算改變後的頁面跟目前的頁面差異，只把需要更改的地方送到瀏覽器

要注意的是
因為 Elixir 語言的特性，可以有極多的 process 同時進行，所以有辦法做到隨時都有一個 process 來為每一個客戶持續的連線，
並統一在 process 裡面管理該客戶端的狀態。

好處是什麼
跟傳統做法相比，不用寫 javascript 來另外操作瀏覽器端的狀態，也可以很簡單的加上豐富的互動。
跟前端框架相比，因為所有的狀態都在伺服器端統一管理，所以不用多一層 api 跟後端溝通，可以直接拿要拿的項目如 context 的內容。