查看原始碼 部署
使用 LiveView 有狀態模型時會出現的問題之一是，什麼考量因素在部署 LiveView 的新版本時是必要的。
首先，每當 LiveView 斷線時，它會自動嘗試使用指數衰退重新連線到伺服器。這表示它會馬上嘗試，接著等 2 秒再嘗試一次，接著 5 秒，以此類推。如果你要部署，這通常表示下次重新連線會立即成功，而且你的負載平衡器會自動重新導向到新的伺服器。
然而，你的 LiveView 可能 在這個過渡中仍然有會損失的狀態。該如何處理？好消息是，你可以遵循一些做法，這不僅有助於部署，還能整體提升你的應用程式。
當適當時，保留在查詢參數中的狀態。例如，如果你的應用程式有標籤，而且使用者按了一下標籤，請使用
<.link patch={...}>透過將標籤名稱作為參數傳遞來執行它，而不是使用phx-click和Phoenix.LiveView.handle_event/3來管理它。接著你會收到新的標籤名稱Phoenix.LiveView.handle_params/3，這會設定相關的 assign 來選擇要顯示哪個標籤。你甚至可以在應用程式路由器中為每個標籤定義特定的 URL。這樣一來，你會減少伺服器狀態的量、提升標籤導覽的分享性（透過連結），提升搜尋引擎索引等等事項。考慮將其他相關的狀態儲存在資料庫中。例如，如果你正在建構一個聊天應用程式，而且想儲存哪些訊息已被讀取，你可以在資料庫中儲存這類資料。當頁面載入後，你會擷取已讀取的最後一則訊息的索引。這會讓應用程式更可靠，並允許在裝置之間同步化資料等等。
如果你的應用程式使用表單（這很可能成立），請記住 Phoenix 會執行自動表單復原：在斷線的情況下，Phoenix 會收集表單資料，並在重新連線後重新提交它。大多數的表單都能以開箱即用的機制運作，但你可能想客製化表單或針對最複雜的表單測試它。請參閱「表單繫結」文件中的相關區段，以深入瞭解。
概念為：如果你遵循上述做法，你應用程式的大部分狀態都已處理妥當，因此部署不應該帶來額外的疑慮。不僅如此，它會為你的應用程式帶來整體上的好處，例如索引、連結分享、裝置分享等等。
如果你確實有無法立即處理的複雜狀態，則可能需要訴求特殊策略。這可能是保留舊狀態至 Redis/S3/資料庫，以及在新連接載入新狀態。或者，你在遷移連接時可能需要特別注意（例如，如果你正在開發一款遊戲，你可能希望等到進行中的工作階段結束後，才停止舊伺服器，同時將新工作階段路由至新伺服器）。這些範例會視你的需求而定（而且它們可能會存在於你使用的任何應用程式堆疊中）。