珠海项目 - 前端技术选型 & Solid 组件拆分

6/10/2025

在框架选择与组件设计之间取得平衡，是我们这次的重点。

从项目立项初期，我们就决定不使用 Vue 或 React 这类主流框架，而是选择了 SolidJS 作为前端开发框架。

这个决定的背景是：

• 项目未来可能运行在离线端设备（iPad）上；
• 我们希望尽可能少依赖 runtime；
• 服务端渲染不是刚需，反而希望组件尽量“纯”。

为什么是 SolidJS？

SolidJS 的最大特点是编译时优化和极小的运行时开销，非常适合构建高度响应、体积轻巧的前端系统。

另外，Solid 的响应系统天然靠近“信号机制”，这对后续我们构建实时 UI（如后台仪表板）也有好处。

当然也有成本：

• 工具链生态相对冷门；
• 组件库偏少，大多需要自研；
• 新手开发者上手门槛略高。

组件拆分的初步规划

我们把整个后台划分为以下模块：

• Dashboard：用于值班端快速查看今日运营情况；
• Orders：订单管理；
• Members：会员与积分；
• Tickets：票种与库存；
• Settings：系统配置与权限管理。

组件命名采用领域优先策略，例如：

• <TicketTable />：票种总览表格；
• <MemberTierSelector />：会员等级选择器；
• <OrderTimeline />：订单生命周期追踪。

这些组件优先满足“复用 +可脱离上下文渲染”的要求。

我们接下来的重点是把这些模块中的交互状态统一交由 solid-store 或信号管理，避免“页面级管理”导致的状态同步混乱。

如果需要，我可以帮你将这篇导出为 Markdown 文件。是否现在导出？