# 开发过程总结与技术参考

本文档总结了 "图纸工作台" 产品原型的开发过程，旨在为后续的开发和维护提供参考。

## 1. 初始需求

项目初期，用户提出了一个三栏布局的图纸编辑平台原型需求：

*   **左侧 (层级结构):** 展示和管理件号的层级关系。
*   **中间 (图纸与表格):** 展示固定的图纸背景，并叠加可拖拽的数据表格。表格内容根据当前选中的件号动态展示其子项信息。
*   **右侧 (数据编辑):** 提供表单，用于编辑选中件号的属性（名称、数量、重量等）。

**核心交互逻辑:**

1.  **数据联动:** 子项数据的变更（如重量）需要自动汇总到所有父项。
2.  **层级管理:** 支持通过输入件号来创建或修改层级关系。
3.  **图纸关联:** 支持将件号与特定的图纸进行绑定。
4.  **操作:** 提供数据校验保存和模拟导出 DXF 文件的功能。

## 2. 技术架构

*   **前端框架:** 采用 **React** (通过 CDN 引入) 进行组件化开发，未使用 JSX，直接使用 `React.createElement`。
*   **状态管理:** 所有应用级别的状态（如图纸、件号、表格位置等）都集中在主组件 `App.js` 中进行统一管理，通过 props 和回调函数的形式传递给子组件。
*   **组件划分:**
    *   `App.js`: 主应用组件，负责状态管理和核心逻辑。
    *   `Header.js`: 顶部栏，包含标题和操作按钮（保存、导出）。
    *   `StructureTree.js`: 左侧层级树视图。
    *   `DrawingViewer.js`: 中间图纸和表格预览区。
    *   `DataEditor.js`: 右侧数据编辑表单。
*   **数据结构:**
    *   **items:** 一个以件号ID为key的对象，存储所有件号的详细信息 (`id`, `name`, `parentId`, `children`, `drawingId` 等)。
    *   **drawings:** 一个以图纸ID为key的对象，存储图纸信息 (`id`, `name`, `url` 等)。
    *   **tablePositions:** 存储可拖拽表格相对于其图纸的位置。

## 3. 功能实现与迭代

### 3.1. 基础功能搭建

按照初始需求，我们首先搭建了应用的静态界面和基础数据流。

*   实现了 `StructureTree`, `DrawingViewer`, `DataEditor` 的基本渲染。
*   在 `App.js` 中利用 `useEffect` 实现了父项重量根据子项自动汇总计算的逻辑。

### 3.2. 核心交互实现

*   **表格拖拽:** 在 `DrawingViewer` 中实现了一个 `DraggableTable` 组件，通过原生 `mousedown`, `mousemove`, `mouseup` 事件处理拖拽逻辑，并更新表格位置状态。
*   **动态创建件号:** 最初，中间视图的输入框用于创建新的子件号。

### 3.3. 需求迭代与重构

在开发过程中，根据用户的反馈进行了几次重要的逻辑调整和重构。

**迭代1: “创建”逻辑变更为“修改”**

*   **需求:** 用户反馈中间视图的输入框应为**修改当前件号**，而非创建子件号。
*   **实现:**
    *   在 `app.js` 中创建了核心的 `handleItemRename` 函数。
    *   该函数负责处理复杂的重命名和移动逻辑：
        1.  从旧父项的 `children` 列表中移除。
        2.  根据新的ID解析出新的 `parentId`。
        3.  **递归地更新所有子孙件号的ID和 `parentId`**，以保持层级ID的一致性（例如，`1-1` 重命名为 `3`，其子 `1-1-1` 会自动变为 `3-1`）。
        4.  将自身添加到新父项的 `children` 列表中，如果新父项不存在则自动创建。

**迭代2: “总装图”根节点的演进**

这是整个开发过程中最核心的重构。

*   **初始需求:** 在结构树顶部增加一个不可修改的“总装图”节点。
*   **第一版实现 (虚拟容器):** 为了解决顶级件号（如 `1`, `2`）的前缀问题，将“总装图”实现为一个UI上的虚拟节点，数据层面顶级件号的 `parentId` 为 `null`。
*   **问题:** 用户指出**“总装图”本身也应该是一张独立的、可绑定的图纸**，是一个真实的节点。虚拟容器方案不符合此要求。
*   **最终实现 (实体根节点):**
    1.  在数据模型中重新引入一个ID为 `__ROOT__` 的实体Item，作为“总装图”。
    2.  所有顶级件号的 `parentId` 都明确指向 `__ROOT__`。
    3.  **重写 `handleItemRename` 逻辑**，规定任何不含 `-` 的件号（如 `3`）的父级都自动归属于 `__ROOT__`。这从根本上解决了顶级件号的归属问题，同时保持了ID的简洁性。
    4.  UI上对 `__ROOT__` 节点进行特殊处理，允许其名称可编辑，但ID不可修改。

**迭代3: UI 优化**

*   **总装图编辑:** 允许用户在右侧 `DataEditor` 中编辑“总装图”的名称。
*   **切换按钮:** 增大了图纸区域左右切换箭头的尺寸，提升了可用性。

## 4. 最终功能概览

*   **实体根节点:** “总装图”是一个功能完整的根节点，可编辑名称、绑定图纸，但ID和层级位置不可变。
*   **层级管理:** 支持通过修改件号ID来自由地重命名和移动节点及其所有子孙节点。
*   **数据联动:** 重量自动汇总。
*   **视图交互:** 图纸可切换，表格可拖拽。
*   **完整操作:** 支持数据校验保存和模拟导出。