函式性純UI元件：morphonent - DEV社群

banq發表於2019-12-31
函式UI元件dev

面對大量的使用者互動和體驗，構建應用變得越來越具有挑戰性。使用者現在需要自然而又快速的豐富互動，並且需要可靠的應用程式。
現在，為了構建這些複雜應用程式時的需求，我們擁有最先進的庫和框架，例如React，Vue，Svelte或Angular等。
此外，我們還面臨著這樣的情況：應用程式狀態管理本身就是一個挑戰，社群為之建立了不同的解決方案，僅舉幾個例子，我們有redux和MobX。當我們還具有對後端的HTTP請求的非同步狀態時，此問題將變得非常複雜。
我個人對分散式體系結構和模式感興趣，但是，我發現對系統前端進行程式設計的複雜性也很有趣，因為它是使用者固有的需求。當我們在每分鐘處理大量請求的後端中時，我們每分鐘交換數千兆的資訊，很容易忘記使用者而將重點放在開始考慮系統本身。
與以前相比，今天構建UI更加容易，便宜和自動化。儘管如此，大多數使用者介面對於使用者（對於單個網頁下載的javascript數量）還是對開發人員而言都是昂貴的，因為一旦構建網頁就很難更改其結構。
我一直在研究如何使UI的更改成本更低，可組合且更易於測試。我得到了以下結論，這些結論將使UI易於更改：
  • 應用程式需要像粘土一樣可成型。
  • 過渡必須合理且易於跟蹤。首選1-1轉換，避免儘可能fan-out。
  • 預設情況下，非同步是真正的快速非同步程式碼。
  • 自動測試應用程式應該與在瀏覽器中呈現應用程式一樣容易。

因此，基於敏捷和XP，我對允許更便宜的UI的庫或框架有以下要求：
  • 為了使應用程式可成型，需要經常更改其結構。
  • 要使過渡自然，過渡應該是應用程式工作原理的基本組成部分。
  • 庫應該以相同的方式理解非同步和同步業務邏輯。
  • 應用程式的每個元件都應該可以獨立且快速地進行測試。

我寫了一個名為的庫morphonent來實現這些想法。但是，我認為，這些模式和設計決策（如果有用）可以建立在其他更健壯且防彈的庫（例如上述庫）的基礎上。這裡重要的不是庫（我為啟用這些模式而構建的庫），而是模式本身。
 

相關文章