首页
/ Delivery Hero 如何用 MUI X 提速 Partner Portal 开发:Data Grid 与 Date Time Picker 的落地案例

Delivery Hero 如何用 MUI X 提速 Partner Portal 开发:Data Grid 与 Date Time Picker 的落地案例

2026-09-07 14:45:11作者:薛曦旖Francesca

本文以 MUI 官方客户案例文档 docs/pages/customers/delivery-hero.md 为主体,完整还原 Delivery Hero 在 Partner Portal 中引入 MUI X(Data Grid 与 Date/Time Pickers)的背景、挑战、方案与成效,并结合 MUI 仓库源码补充说明该案例在文档站中的落地机制:frontmatter 元数据如何被解析校验、案例页面如何渲染、以及如何被聚合进 Customers 列表页。

背景:Delivery Hero 与 Partner Portal

Delivery Hero 是覆盖约 70 个国家的本地配送平台,通过技术驱动的即时配送方案连接消费者与餐厅、商店及各类生活服务。其面向商家侧的 Partner Portal 为餐厅和供应商提供运营工具,帮助他们更高效地管理日常业务、提升顾客体验并持续优化经营表现。

案例文档中引用了 Delivery Hero 工程团队负责人的一段评价:

"By leveraging the Date Time Picker and Data Grid, we have been able to provide our customers with cutting-edge, well-designed features in a shorter development time and with less effort." —— Ahmed Ibrahim, Senior Manager Software Engineering, Vendor Growth

即:借助 Date Time Picker 与 Data Grid,团队以更短的开发周期、更少的投入,向客户交付了设计精良的前沿功能。

采纳 MUI X 之前面临的两大挑战

根据原文档,Delivery Hero 团队在引入 MUI X 之前主要受两个问题困扰:

  1. 开发速度慢,响应滞后。修复供应商报告的 bug、实现功能需求都耗时较长——构建、测试、打磨 UI 组件是一个缓慢的过程。
  2. 体验一致性难以保证。为最终用户确保一致、易用且高性能的使用体验存在困难。

这两点本质上是 B 端产品常见痛点:商家侧运营工具功能繁多、迭代频繁,自研通用 UI 组件(表格、日期选择器等)的维护成本会不断摊薄业务开发资源。

解决方案:集成 Data Grid 与 Date/Time Pickers

为应对上述问题,Delivery Hero 团队在平台中集成了 MUI X 的 Date/Time PickersData Grid 两类组件。文档总结了三方面收益:

  • 加速开发:使用预构建的高质量组件,减少了 UI 实现上花费的时间;
  • 提升易用性:现代、精致(sleek)的 UI 改善了用户交互与视觉一致性;
  • 优化性能:为餐厅和店铺管理者提供流畅的使用体验。

值得注意的是方案选型与业务场景的对应关系:Partner Portal 作为商家运营后台,大量涉及数据密集界面(订单、经营数据表格),Data Grid 直接命中这一核心场景;而商家运营中频繁出现的时间选择(营业时间、排班、预约时段等)则由 Date/Time Pickers 覆盖,这与下文的"减少点击次数"成效相互印证。

实施成效:开发提速,点击次数显著下降

引入 MUI X 后,团队很快看到收益:UI 开发变得更快速、更高效,从而把更多时间投入到业务功能本身。

其中最具代表性的成功点是 Date Time Picker 的落地:它显著减少了用户达成目标所需的操作次数(clicks)。这一看似简单的交互改进,直接提升了用户的操作效率与满意度——对高频使用 Partner Portal 的商家而言,每次少点几步都意味着真实的生产力收益。

开发者体验:文档是落地顺畅的关键

团队对 MUI 文档给予高度评价,形容其"清晰、结构良好、易于遵循"(clear, well-structured, and easy to follow),使开发者能够毫不费力地完成组件的集成与定制。文档原文的最后一段是面向同类开发者的推荐结论:对于希望以最小投入构建现代、高性能 UI 组件的团队,Delivery Hero 团队力荐 MUI X。

仓库佐证:该案例在 MUI 文档站中的实现机制

以下结合仓库源码说明这个客户案例页是如何被组织、校验与渲染的,可作为阅读同目录其他案例(docs/pages/customers/ 下还有 AT&T、CGI、Coupa 等)的通用参考。

1. frontmatter 元数据:标签白名单与排序权重

docs/pages/customers/delivery-hero.md 的 frontmatter 声明了 titledescriptionimage(指向 /static/branding/companies/deliveryhero_spotlight.svg)、tags: ['MUI X']rank: '7'manualCard: true

其中 tags 受仓库白名单约束:在 docs/lib/sourcing.ts 中,ALLOWED_TAGS 数组列出了允许出现的博客/案例标签,产品类标签包括 Material UIBase UIPigment CSSJoy UIMUI XToolpad 等,出现白名单之外的标签会在构建期抛出 not whitelisted 错误(该逻辑主要在 getAllBlogPosts 的标签统计环节生效)。rank 字段则用于案例卡片在 Customers 列表页中的排序展示。

image 字段对应的文件实体位于仓库静态资源目录,可确认为 docs/public/static/branding/companies/deliveryhero_spotlight.svg,与文档正文引用的横幅图 docs/public/static/branding/companies/headers/deliveryhero-header.png 一一对应。

2. 页面渲染:md 内容通过 ?muiMarkdown 导入并由统一布局承载

每个案例都由一个同名的 .js 页面文件挂载。以 docs/pages/customers/delivery-hero.js 为例,它仅做两件事:通过 import { docs } from './delivery-hero.md?muiMarkdown' 导入解析后的 markdown 文档对象,再交给 TopLayoutCaseStudy 组件渲染。

docs/src/modules/components/TopLayoutCaseStudy.js 是案例页的通用布局,其中有几个值得留意的实现细节:

  • 正文宽度:常量 BLOG_MAX_WIDTH = 692(注释说明是参考 Medium 的取值),并在 md/lg 断点下递增左右边距,保证长文阅读的行宽舒适;
  • manualCard 校验:服务端运行时会检查 markdown 头部的 manualCard 字段,缺失则抛出 the "manualCard" markdown header ... is missing 错误——这正是 Delivery Hero 文档 frontmatter 中 manualCard: true 存在的原因(该案例使用手工提供的卡片图而非自动生成);
  • SEO 结构化数据:向 <Head> 注入 schema.orgArticle JSON-LD,包含标题、描述、关键词(取 tags 拼接)等信息,方便搜索引擎理解这篇案例文章的语义;
  • 正文渲染:通过 RichMarkdownElement 逐段渲染 markdown 块,并禁用广告位(disableAd)。

文档正文中那段带内联样式的引用块(区分 only-light-mode / only-dark-mode 两套配色)也是利用该 markdown 渲染链路透传内联 HTML 实现的,保证在明暗两种主题下视觉一致。

3. 聚合入口:Customers 列表页如何发现这篇案例

案例列表页 docs/pages/customers.tsx 在服务端通过 getStaticProps 调用 docs/lib/sourcing.ts 中的 getCaseStudies()。该函数扫描 docs/pages/customers 目录下所有 .md 文件,逐个调用 getCaseStudyPost() 解析 frontmatter(基于 @mui/internal-markdowngetHeaders),生成包含 slugtitledescriptionimagetagsrank 等字段的案例元数据,再经 CustomersSpotlight 组件以卡片网格形式展示,点击卡片即跳转至各案例详情页。

也就是说,delivery-hero.md 的 frontmatter(尤其是 rankimage)直接决定了它在 Customers 列表页中的展示位置与卡片图,而正文则由 delivery-hero.js + TopLayoutCaseStudy 承载——元数据与内容在仓库中是清晰分离的。

小结

这个案例的价值在于它展示了一条可复用的 B 端提速路径:先用 Data Grid 承接数据密集界面,用 Date/Time Pickers 压缩高频交互的操作成本,再借助文档与开箱即用的组件定制能力保持多端一致性。对评估 MUI X 的团队,Delivery Hero 的实践给出的参照是:把"构建和测试 UI 组件"的时间从业务开发中剥离出来,往往能同时改善交付速度与终端用户的点击效率。

延伸阅读:仓库 Blog 目录(docs/pages/blog/)中收录了多篇 MUI X 产品文章,如 docs/pages/blog/introducing-mui-x-data-grid-v9.md 等,可对照了解 MUI X 各版本的能力演进。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
1.13 K
2.75 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件,TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件,使 PyTorch 框架能够直接调用昇腾 NPU,为开发者提供昇腾 AI 处理器的超强算力。
Python
857
1.35 K
docsdocs
暂无描述
Markdown
897
5.8 K
kernelkernel
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
529
593
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
915
1.83 K
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
3.58 K
1.01 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.35 K
1.46 K
cann-learning-hubcann-learning-hub
CANN 学习中心仓,支持在线互动运行、边学边练,提供教程、示例与优化方案,一站式助力昇腾开发者快速上手。
Jupyter Notebook
1.01 K
515
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR(Multi-Level Intermediate Representation)构建的,面向昇腾亲和算子编译时使用的中间表示,提供昇腾完备表达能力,通过编译优化提升昇腾AI处理器计算效率,支持通过生态框架使能昇腾AI处理器与深度调优
C++
547
388