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：Vistual Stuidio + 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 調用加載，並生成 angualr、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