6.1 框架与组件化：三班合成一支队伍

6.1 框架与组件化：三班合成一支队伍

本节摘要：框架解决的核心矛盾是手动投影的规模瓶颈——数据一多、界面一复杂，手工保持"页面等于数据"的成本失控。框架的思路是声明式渲染：你描述状态与模板，框架负责投影与更新。组件化则把结构、样式、行为打包成可复用零件。本节用看板对照演示框架思维，并梳理主流框架的取向差异。

一、手动投影的天花板

第 4 章的看板运转良好：数据变了调渲染函数，页面整体重画。把规模放大看看：页面涨到几十个区块、数据来自五六路接口、状态之间互相牵连（筛选条件变了要重拉数据、数据变了要重算统计、统计变了要更新三处显示）——"哪个数据变了要更新哪片页面"这张映射表，在人脑里开始放不下。手工投影的天花板不在技术，在人脑维护映射关系的容量。

历史上的应对方案曾是把"数据变了重画全部"推到极致：整体重画、无脑同步。简单粗暴有效，但每次改动都全页重建，交互一密性能就崩。框架的突破在于精准化：自动算出"数据到页面的最小更新集"——你只管改状态，框架算出哪几个节点该动、动哪几个属性，更新精确到点。

图 1：前端框架演进时间线

二、声明式：从"怎么做"到"长什么样"

手工投影是命令式的：查节点、改节点、逐处交代。声明式反过来：描述"界面对这种状态时长什么样"，状态一变框架自动把界面调过去。两段对照代码感受差别——同样一件事，工单列表按加急排序。

// 命令式（本册第 4 章的姿势）：一步步交代怎么做
function sortByUrgent() {
  const sorted = [...orders].sort((a, b) =>
    (a.priority === "urgent" ? 0 : 1) - (b.priority === "urgent" ? 0 : 1));
  renderOrders(sorted);            // 手动触发重画：忘记调用页面就不变
  saveOrders(sorted);
  renderStatsBar(summarize(sorted));
  // 每一个牵连处都要自己记得调——漏一处就出现"数据与页面打架"
}
​

// 声明式（框架的姿势）：只描述长什么样
// 以主流框架的通用形态示意（各家语法略异，思想一致）：
//
// 状态：const orders = ref([])
// 模板：
//   <tr 对 orders 中的每张工单>
//     <td>{{ order.no }}</td>
//     <td>{{ order.product }}</td>
//     <span class 徽章 :按 order.status 着色>{{ 状态文字 }}</span>
//   </tr>
//
// 排序按钮的处理函数只剩一件事：
//   orders.value = 排序后的数组
//
// 页面更新？框架的事。统计联动？若统计也由状态推导，同样自动。

// 对照结论：
// 命令式的复杂度在"维护同步"，声明式的复杂度在"设计状态结构"
// 前者随规模线性膨胀，后者在状态设计好之后近乎恒定
​

第二段是示意代码，刻意用中文描述代替具体框架语法——各家方言不同，思想完全一致：状态是唯一事实，模板是状态的函数。你在第 4 章手工维持的投影纪律，框架用机器替你维持了。

三、组件：把三班打包进一个零件

组件化解决复用问题。看板里的"工单行"由一段结构（单元格与徽章）、一段样式（斑马纹与状态色）、一段行为（点推进换状态）组成——三班成果围绕同一件事，却分散在三份文件里。组件把它们打包：一个零件对内封装三班实现，对外只暴露属性（给它什么数据）与事件（它通知你什么）。用的时候像搭积木，传不同的数据得到不同表现的同一零件。

组件视角的看板分解：

页面 = 页头组件 + 统计栏组件 + 工单表组件 + 登记表单组件 + 侧栏组件

工单表组件
  对内：表格结构、斑马纹样式、行点击逻辑——三班私有
  对外：属性（工单数组）、事件（状态变更通知）——公共接口

工单行组件（工单表内部再拆的更小零件）
  对内：徽章着色规则、推进按钮
  对外：属性（单张工单对象）

复用场景：质检页也要显示工单行？直接搬工单行组件，
传质检口径的数据即可——结构与逻辑零复制
​

// 用原生自定义元素演示组件形态（无需框架）：
// 组件对外的使用方式，长得像普通标签：
//   <order-row no="MO-1042" product="凸轮轴" status="running">
//   </order-row>
// 内部实现三件事（示意框架帮你做的事）：
class OrderRow extends HTMLElement {
  connectedCallback() {                    // 零件上树时
    const shadow = this.attachShadow({ mode: "open" });
    // 影子根：组件的样式与结构封装在此，内外互不污染
    shadow.innerHTML = `
      <style>
        .badge { padding: 2px 10px; border-radius: 10px; }
        .running { color: #1a6ec8; background: #e3f0ff; }
      </style>
      <span part="no"></span>
      <span class="badge"></span>`;
    shadow.querySelector("[part=no]").textContent = this.getAttribute("no");
    const badge = shadow.querySelector(".badge");
    badge.textContent = { running: "加工中" }[this.getAttribute("status")] ?? "未知";
    badge.classList.add(this.getAttribute("status"));
  }
}
// 浏览器原生支持把自定义标签关联到这个类——
// 框架组件是这套思想的强化版：属性响应、状态管理、批量更新
​

四、三大框架的取向与选型

主流框架三家并立多年：一家以渐进式与模板亲和著称，上手曲线平缓、生态全面；一家以组件模型与庞大生态著称，就业面最宽；一家以完整工程化著称，强约束换来大团队的一致性。三家实现细节各异，内核都是"状态驱动视图"——这正是不必纠结选哪家的原因：地基通了，换方言是周级成本。选型真正该考虑的是目标公司的技术栈与社区资料的可得性，而不是"哪家更强"的口水战。

⚠️ 常见坑：跳过地基直接学框架，语法会了、原理不通——框架报错时看不懂它操作的是哪棵树、优化指引里的"减少重渲染"不知所云。本册反复铺的地基（选择器、盒模型、节点树、事件、异步）恰恰是框架文档里不再解释的部分。

💡 关键直觉：判断该不该上框架的成本线——当"状态与页面的同步关系"开始需要写文档才能说清，就到了框架的门槛；在此之前的内部工具、活动页，原生三件套反而是最快最稳的方案。

本节要点回顾

• 核心矛盾：手动投影的瓶颈是人脑维护"数据到页面"映射表的容量，不是技术；
• 声明式内核：状态是唯一事实、模板是状态的函数，同步交给框架；
• 最小更新：框架自动算出数据变化对应的最小界面改动，替代整体重画；
• 组件本质：三班成果对内封装、属性与事件对外暴露，复用像搭积木；
• 影子封装：原生自定义元素已能演示组件形态，框架是强化版；
• 选型务实：内核相通、方言可换，按团队与资料选，不按口水战选。

框架的"为什么"清楚了，下一节看"怎么做"：构建工具链如何支撑机器化施工，并领走你的进阶路线图。