---
title: "Signal狀態和Form"
date: "2026-04"
category: "Angular"
tags: ["Angular"]
description: "Angular有一個地方和React不太一樣，這裡的屬性變動本身就會觸發重新渲染，在React那邊就必須要狀態。而另一個方面則是這裡的服務函式，這個是全局單例，所有元件共享狀態..."
source: "https://enriquemark.com/zh-hant/posts/Signal%E7%8B%80%E6%85%8B%E5%92%8CForm"
---

Angular有一個地方和React不太一樣，這裡的屬性變動本身就會觸發重新渲染，在React那邊就必須要狀態。而另一個方面則是這裡的服務函式，這個是全局單例，所有元件共享狀態。不過官方的推薦寫法還是寫到Signal裡，不然直接屬性更新會遍歷檢查，有效能開支，未來可能會刪掉這種因為屬性更改而觸發的渲染更新了。但即便如此，Signal和State也還是不同的，我在[MVC和MVVM](/zh-hant/posts/MVC和MVVM)那裡説到過這點，那就是DOM全局檢查這方面，React的效能開支還是比Signal大的，後者是直接定位。

而除此之外這裡還有一個點，那就是作為狀態的Signal，和作為資料儲存結構的form——這兩者是有自身單獨的使用場景的。如果不涉及到資料，而只是單純的UI狀態識別，那就應該用Signal，這是字面意義上的「渲染的訊號」。而資料則不然，雖然資料也可以塞到Signal裡，但如果要對其進行核驗那就得自己寫一系列檢查方法，這裡反倒不如用官方封裝好的form。況且，如果我要把資料繫結到html，那form天然雙向繫結和良好的支援都是更合適的選擇。

也就是需要驗證，需要送api，需要提交的「資料」，使用form是最佳的。上述之外，單純的繫結到表單的渲染狀態，或者是某種暫存的資料——最終要同步到form——去的，就用Signal會比較沒問題。

濫用Signal和濫用form沒什麼本質區別，比如把資料往Signal裡塞（從React轉過來，把這個直接當state用）；或者是反過來把比渲染狀態都塞到form裡。最終造成職責和邊界都不清晰，混在一起，簡直是地獄繪圖。會造成很大的維護負擔，長久成為技術債。
