Rust 全栈项目里，我写了一个不再重复造轮子的泛型表格组件

最近在用 Rust Leptos 写一个家政行业的 CRM 系统后台管理页面里表格是绝对的主角——客户列表、订单列表、排班列表、服务项目列表……每个页面都要一个表。刚开始我也是老老实实每个页面手写table写了三个页面后实在受不了了于是抽了一个泛型表格组件出来。这篇文章就来聊聊DaisyTable的设计思路和其中 3 个关键模式。问题为什么手写表格撑不住传统的做法很简单每个页面自己写For循环渲染行每行自己写td。看起来没问题但三个页面后你会发现排序、加载态、空状态每个页面都要重写一遍列定义散落在视图代码里维护起来得扒拉半天操作列里的查看/编辑/删除按钮每行拿当前行数据的方式各不相同目标很明确定义一个泛型表格用一个数据结构描述有哪些列每个列自带渲染逻辑行数据通过 Provider 机制自动注入排序、加载态、空态全部内置。设计一Column 插槽 —— 用声明式 DSL 描述列Leptos 的#[slot]宏让我们可以定义插槽组件——父组件接收一组子组件作为配置项。Column 就是这样一个插槽#[derive(Clone)]#[slot]pubstructColumn{publabel:String,#[prop(default false)]freeze:bool,#[prop(default false)]sort:bool,prop:String,#[prop(optional, into)]pubclass:OptionString,pubchildren:ChildrenFn,}使用时就是一个声明式的 DSL列定义和渲染逻辑写在一起DaisyTabledatadata on_sorton_sortColumnslot:columns freezetruepropuser_name.to_string()label姓名.to_string()classfont-boldsorttrue{letuser:OptionContactuse_context::Contact();view!{span classfont-medium{user.map(|u|u.user_name).unwrap_or_default()}/span}}/ColumnColumnslot:columns label电话.to_string()propphone_number.to_string(){letuser:OptionContactuse_context::Contact();view!{span{user.map(|u|u.phone_number).unwrap_or_default()}/span}}/Column// ... 更多列/DaisyTable每个 Column 的children是一个闭包由表格内部在渲染时调用你只管定义这一列长什么样。freeze列渲染为th表头单元格样式普通列渲染为td。设计二Provider 注入 —— 子组件无感获取当前行数据这是整个设计里最巧妙的地方。看表格内部的渲染逻辑Foreachmove||items key|item|item.id()childrenmove|item|{view!{ProvidervalueitemtrForeachmove||columns key...childrenmove|(_,col)|{ifcol.freeze{view!{th class...{(col.children)()}/th}}else{view!{td class...{(col.children)()}/td}}}//tr/Provider}}/注意Provider valueitem把当前行数据注入了上下文。所以每个 Column 的 children 闭包里可以直接use_context::T()拿到当前行数据不需要手动传参、不需要闭包捕获、不需要索引访问。举个例子操作列里需要当前行的contact_uuid来做编辑和删除传统做法要通过闭包层层传参而这里直接Columnslot:columns freezetruelabel操作.to_string()prop.to_string(){letuser:OptionContactuse_context::Contact();letuuiduser.map(|u|u.contact_uuid).unwrap_or_default();view!{button on:clickmove|_|delete(uuid.clone())classbtn btn-ghost btn-xs删除/button}}/ColumnProvider 充当了当前行作用域的角色。每一列的子组件不用知道自己在第几行、数据怎么传进来的——直接从上下文拿即可。设计三Identifiable —— 让 Leptos 精确知道谁变了Leptos 的For组件需要一个稳定的key来判断列表项的新增、删除和移动。所以我们定义了一个 traitpubtraitIdentifiable{fnid(self)-String;}业务数据类型只需实现它implIdentifiableforContact{fnid(self)-String{format!({}-{},self.contact_uuid,self.updated_at)}}为什么要拼updated_at如果只用contact_uuid编辑某个客户后数据刷新了但 key 没变Leptos 不会重新渲染对应行。把updated_at拼进去后每次编辑产生新数据时 key 就会变对应行自然重新渲染。DaisyTable的泛型约束直接限定T: Identifiable编译器强制你在使用前思考 key 怎么定义反过来也避免了忘记给For设置key的常见 bug。再看看排序和加载态排序内置在表头里。Column设置sorttrue后表头自动渲染一个ColumnSorter组件// ColumnSorter 内部点击切换 Asc - Desc回调通知父页面lethandle_clickmove|_|{letnew_valuesort_value.read().reverse();set_sort_value.set(new_value);ifletSome(f)on_change.as_ref(){f(new_value);// 通知页面重新请求数据}};加载态和空状态也内置了。Transition组件包裹tbody——数据没准备好时自动渲染 loading 动画数据为空时自动展示暂无数据。这些原本每个页面要手写的逻辑全部收到表格内部了。总结三个核心模式Column 插槽声明式列定义列结构和渲染逻辑在一起一眼看清这个表有哪些列Provider 注入Provider valueitemuse_context列子组件无感获取当前行数据零参数传递Identifiable trait编译器强制定义稳定 key避免渲染漏更新整个DaisyTable组件含 ColumnSorter不到 200 行代码但已经支撑了 Pico-CRM 里 6 个页面的全部表格渲染——客户管理、订单列表、排班管理、服务项目、商户管理、员工管理。新增一个列表页面只需要实现Identifiable然后写几个Column标签排序、加载态、空态全部自动到位。如果你也在用 Rust 写全栈Leptos / Dioxus / Yew这种 Provider Slot 的组合在列表、表单、详情页等场景都可以复用。项目开源在 GitHub。大家在自己的项目中是怎么处理表格组件的评论区聊聊。