Blazor 開源元件庫 - Masa Blazor

官方說明 Blazor

Blazor 允許您使用 C#而不是 JavaScript建置互動式 Web UI。 Blazor 應用程式由可重複使用的 Web UI 元件組成，這些元件使用 C#、HTML 和 CSS 實作。用戶端和伺服器端程式碼都是用 C# 編寫的，允許您共用程式碼和函式庫。

Blazor 是一個使用 .NET 產生互動式用戶端 Web UI 的框架：

使用 C# 代替 JavaScript 來建立資訊豐富的互動式 UI。
共用使用 .NET 編寫的伺服器端和用戶端應用程式邏輯。
將 UI 呈現為 HTML 和 CSS，以支援眾多瀏覽器，其中包括行動瀏覽器。
與新式託管平台（如 Docker）整合。

使用 .NET 進行用戶端 Web 開發可提供以下優勢：

使用 C# 代替 JavaScript 來編寫程式碼。
利用現有的 .NET 函式庫生態系統。
在伺服器和用戶端之間共用應用程式邏輯。
受益於 .NET 的效能、可靠性和安全性。
在 Windows、Linux 和 macOS 上使用 Visual Studio 保持高效工作。
以一组穩定、功能豐富且易用的通用語言、框架和工具為基礎來進行開發。

看到這裡有些小夥伴手中的瓜已經要丟出來了，的確有部分是誇大了的，起碼 VS 在三個平台高效工作這事兒，嗯。。。其他的繼續吃瓜吧

Blazor Vs MVC

什麼是 MVC

官方說明：ASP.NET Core MVC 是使用「模型-檢視-控制器」設計模式建構 Web 應用程式和 API 的豐富框架。

圈重點，Blazor 是互動式 Web UI，而 MVC 是 Web 應用程式和 API

什麼是互動式 Web UI

谷歌、百度轉了一圈，沒有這個解釋，連 Wiki 也是一臉懵逼。

嘗試理解一下吧，互動式 Web UI 重點在於互動，而 Blazor 的官方說明是用 C#代替 JavaScript，那我們看看 JavaScript 有什麼功能，我百度找一段過來：

嵌入動態文字於 HTML 頁面
對瀏覽器事件做出回應
讀寫 HTML 元素
在資料被提交到伺服器之前驗證資料
檢測訪客的瀏覽器資訊。控制 cookies，包括建立和修改等

有這些基礎功能，用戶不需要在靜態頁面裡跳來跳去了，的確體驗會好很多

Blazor 有什麼優勢

提供了一些互動能力，不再是純粹的靜態頁，雖然 MVC 可以使用 JavaScript 達到同樣的效果，但你需要掌握 JavaScript，甚至還要再學習 jQuery、Angular、Vue 等。而 Blazor 提供的互動能力則是使用 C#。

吹是吹完了，但你真的可以 100% C#嗎？這很難，你會遇到各種問題，比如相容性、效能等。好了，那我可以不用了嗎？等等，下面還有瓜

Blazor Vs 現代前端(Angular、Vue 等)

我們從幾個方面來比對一下吧

偵錯

Blazor：Visual Studio + F5，VS Code/命令列工具 + dotnet watch

比 WebPack 要快很多，跟 Vite 差不多

在非複雜場景下 Hot Reload 是可以的，但奇奇怪怪的問題太多了，前景很好，目前來看還是用 Ctrl + F5 啟動或者用命令列吧

VS 2022 的 Ctrl + F5 已經支援 Hot Reload 了

現代前端：Webpack/Vite

全家餐

以 Vue 為例，Vue 全家餐包括 Vue Cli、Vue Router、Vuex

Blazor：

Cli：dotnet cli
Router：Microsoft.AspNetCore.Components.Routing.Router
Vuex：Blazor 狀態管理，區別在於 WASM 狀態保存在瀏覽器記憶體中，而 Server 保存在伺服器記憶體中。而且 Blazor 狀態管理更強大的是藉助 .NET 的能力，原生支援持久化儲存、跨線路保存（Server 下共用伺服器記憶體）、ASP.NET Core 受保護的瀏覽器儲存（Server 獨享功能）

元件庫

主流的 Bootstrap, Ant Design, Material Design 等雙方都有。但由於現代前端多年的積累，品質上的確有一定差距。

除了豐富程度上，Blazor 允許被 JavaScript 呼叫載入，並產生 Angular、React 等元件。

雖然這看起來跟用 C# 解決代替 JavaScript 有點衝突，但融入大環境也是不錯的

下圖演示的是 Blazor 提供的 inventory-grid Component 被 React 引用的例子(當然也可以給 Angular)：

更神奇的是，在 React 複用的 Blazor Component 居然也支援 Hot Reload。先不說 Hot Reload 到底如何，單是這個方向其實還是值得期待一下 Hot Reload 的未來吧。

不止可以給 React 提供複用的元件，還可以給 WPF

第三方函式庫

舉幾個前端常用庫來比較。

網路：現代前端有 axios，Blazor 有 HttpClient
資料操作：現代前端有 Lodash，Blazor 有 Linq
時間：現代前端有 moment.js、Day.js，Blazor 有 DateTime 全家桶
響應式程式設計：現代前端有 rx.js，Blazor 有 Rx.NET（沒有用過，理論上 .NET 基本都能用，歡迎糾錯）
Mock：現代前端有 Mock.js，Blazor 有 Moq，當然除了 mock 以外還有端到端的，雙方也都有。

對比下來其實 .NET 反而還有點優勢，那就完美嗎？當然不是，再說點劣勢的部分吧。

Charts：現代前端有 ECharts 等，Blazor 不想說話

雖然目前 Blazor 的確沒有成熟、免費的 Charts 元件庫，但因為 Blazor 可以與 JS 互動的能力，呼叫 ECharts 也很簡單，稍微考驗一點點小夥伴的動手能力

富文本編輯器、拖拽。。。
Blazor 罵罵咧咧的退出了群聊。。。

套件管理

Blazor：NuGet
現代前端：NPM、Yarn

效能

資料不直觀，先從 .NET Conf 2021 上的示範截圖看一下：

有量化資料嗎？有：

影片網址：https://sec.ch9.ms/ch9/daba/468d5211-982b-4c86-8b51-e1c8824edaba/dotNETConfNewBlazorWebAssembly_high.mp4

那 AOT 可以解千愁嗎？也不是。起碼應用大小上來說的確也大了不少，但這並不妨礙 AOT 可以解決特定場景的問題。技術總要選擇在適合的場景使用它，而不是盲目的。

完了嗎

當然沒有，其實這樣比較對於 Blazor 是不公平的，因為 Blazor 站在 .NET 的肩膀上有更多的亮點，比如原生支援的泛型、DI、物件導向設計（雖然 TS 也是）、數不過來的 .NET 類別庫、跨平台應用（MAUI）等。

其實沒有必要只看到 Blazor 的劣勢，也可以看看站在 .NET 上的前端能走多遠，這不也是我們期待的嗎？

看到這裡，有些 .NET 古董級大佬要出來發話了，Silverlight！是的，但這次 WASM 沒有再要求下載插件了。

Web Assembly Vs Server（伺服器端渲染）

Web Assembly：WebAssembly 是一種新的編碼方式，可以在現代的網路瀏覽器中執行－它是一種低階的組合語言，具有緊湊的二進位格式，可以接近原生的效能執行，並為諸如 C / C++ 等語言提供一個編譯目標，以便它們可以在 Web 上執行。它也被設計為可以與 JavaScript 共存，允許兩者一起工作。
Server（Server Side Render - SSR）：將元件渲染為伺服器端的 HTML 字串，將它們直接發送到瀏覽器，最後將這些靜態標記「啟動」為用戶端上完全可互動的應用程式。

為什麼用 SSR

伺服器端渲染 (SSR) 的優勢主要在於：

更好的 SEO，由於搜尋引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
更快的內容到達時間 (time-to-content)

什麼時候用 SSR

使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：

開發條件所限。瀏覽器特定的程式碼，只能在某些生命週期鉤子函數 (lifecycle hook) 中使用；一些外部擴充套件庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程式中執行。
涉及建置設定和部署的更多要求。與可以部署在任何靜態檔案伺服器上的完全靜態單頁面應用程式 (SPA) 不同，伺服器渲染應用程式，需要處於伺服器端執行環境。
更多的伺服器端負載。

伺服器端渲染 vs 預渲染 (SSR vs Prerendering)

如果你調研伺服器端渲染 (SSR) 只是用來改善少數行銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 Web 伺服器即時動態編譯 HTML，而是使用預渲染方式，在建置時 (build time) 簡單地生成針對特定路由的靜態 HTML 檔案。優點是設定預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。

Blazor Server 支援 Prerendering

Blazor 該選 Web Assembly 還是 Server

看一下 .NET Conf 2021 大會上的一張圖：

總結一下：

Server 要持久化長連線，有更高的 UI 延遲
Web Assembly 則是更大的下載大小，和更慢的執行時期效能

我們在做什麼

又是一個老生常談的問題，.NET 的涵蓋面太廣了也導致很難解決所有問題。我們在權衡利弊之後是不是可以為 .NET 生態共建出自己小小的一份力呢？

開源的元件庫

再回到元件庫上，目前市面上的元件庫其實不少了，何必要繼續在這個泥潭裡插一腳呢？

開發過元件庫的同學，或者貢獻過原始碼的同學應該都體會到了，寫一個元件是多麼的複雜。而大家對於一個設計的審美角度也是不同的。當你喜歡的設計沒有提供實作怎麼辦？從頭寫嗎，那太累了，所以我們嘗試了一件事情。

先看一下大概思路：

架構圖

簡單的剖析一下：

在 Blazor 的基礎上，建立一個新的元件庫叫 Blazor Component

那他有哪些特性呢？

只提供互動，不提供樣式
標準化 DOM 結構
開放幾乎所有可以自訂的 Slots（插槽，概念引自 Vue），允許你替換 Slots 的 DOM

插槽與互動的統一單元測試（目前正在 38%，短期目標是 80%，長期目標是 90%+）
基於 Material Design（樣式引自 Vuetify）的範例專案，可以達到生產可用（我們自己的公司在用，也是世界五百強企業在用的）
快速實現新的元件庫，只需要基於某個 Design + 樣式控制屬性 + 特殊互動即可

未來是值得憧憬的，我們希望未來是這樣的：

慚愧，蹭了一波位元組的熱度

MASA Blazor

基於 Blazor Component 和 Material Design 的 Blazor 元件庫

截止目前共 68 個基礎元件，後續會繼續增加
預置元件，提供與 .NET 功能深度整合且常用組合類元件，如 Url、麵包屑、選單三連動，進階搜尋，i18n 等
MASA Blazor Pro 提供多種常見場景的預設佈局
全職團隊維護，Issue 快速回應
知名企業在用，未來 MASA Stack 產品線也將一直使用，持續增加新功能
免費、開源

我們還計劃未來支援一鍵切換主題（程式碼切換已經提供）、預置佈局、資料展示類元件、WorkFlow 類元件等。

MASA Blazor Pro

基於 MASA Blazor 提供的 Admin 模板，先放幾張設計稿吧，原始碼會跟 MASA Blazor 一起放出。

MASA EShop

基於 MASA Framework 搭建的 EShopOnDapr，將會使用 MASA Blazor Pro 提供完整的前後端範例

eshop

開源網址：https://github.com/masalabs/MASA.EShop

總結

說到底沒有完美的技術，在你權衡利弊之後在正確的場景使用它就是最合適的。

是春天還是寒冬也不重要，重要的是當下這一刻，它是否解決了你的痛點。

最後，一個小小的廣告

MASA Blazor 即將發布，敬請期待，如果你對我們的元件庫感興趣，無論是程式碼貢獻、使用、提 Issue，歡迎聯繫我們

參考

歡迎加入技術交流群: MASA Stack