# NJWL Table 2.2.0 · 接入入口

基于 CRM 当前控件抽取。先使用组件，不重新写排序、分组、顺序弹窗或列拖动。组件没有遥测、不包含数据或认证凭证，不自行连接业务接口。

1. 将此包安装到项目的 `vendor/njwl-table`：

```text
python component.py install D:/你的项目/vendor/njwl-table
```

2. 同源加载该目录的 `njwl-table.css`、`njwl-table.js`。也可由构建工具原样打包进现有静态资源；保留 `component.lock.json`，不得手改构建输出。
3. 复制 `example.html` 的字段配置，替换虚构 rows，按 `API.md` 接上读取/写入/视图存储。后端继续校验权限和版本，不把私钥放入配置。
4. 部署前执行 `python component.py verify D:/你的项目/vendor/njwl-table`，再运行应用自己的虚构数据测试。

## 在具体 chat 中改功能

字段标题、数据映射、默认排序、业务权限和已有扩展接口属于应用配置，不需要 fork。要改组件内部行为，先登记分叉：

```text
python component.py fork D:/你的项目/vendor/njwl-table --name your-project-feature
```

然后只修改该目录中的组件源码，保留 `.upstream` 原版和锁文件。把新增特性、兼容影响及虚构测试写入 FEATURE.md，再生成回送材料：

```text
python component.py propose D:/你的项目/vendor/njwl-table --output D:/你的项目/feature-proposal
```

提案含差异补丁、母版本、修改文件哈希和需求说明。它不会自动上传、自动合并或改动其他网站。将提案交给维护母组件的 chat；维护者评估后选择通用特性、可选扩展或业务专用实现，运行回归检查，再发布一个新版本。

其他项目明确选择新版本，先在单独目录安装并核对差异，通过测试后替换部署。存在本地分叉时，用 `.upstream` 原版、本地改版和新母版做三方合并；不要直接覆盖。2.2.0 不提供自动合并。

给后续 chat 的最小上下文：本文件、component.lock.json、应用字段适配文件；有分叉时加 component.fork.json 和 FEATURE.md。其余实现直接阅读组件源码。

## 来源和边界

`provenance.json` 记录 CRM 原源码哈希及抽取函数。排序条、方向菜单、自定义顺序编辑器、分组条、列拖动、列宽与基础编辑交互由本包维护。CRM 的公司同步、评分、维护历史、整行新增和标签业务仍在 CRM 适配层，通过组件扩展接口连接。不要把这些业务能力描述为任何新表默认具备。


## 1.1 新增网址链接

标准 mount 单元格默认自动识别完整 HTTP(S) 网址及裸域名。字段用 autoLink:false 强制禁用。用户可在工具栏“链接设置”关闭整列，也可编辑时取消“显示为超链接”或点击单元格 ⋯ 单独设置。链接文字旁的“编辑”按钮用于编辑网址，网址本身保留原生点击与键盘打开行为。

单项设置需要稳定记录 ID（rowKey、id 或 uid），绑定记录、字段和原值；排序不会串到其他行，值变化不会错误沿用旧地址设置。关闭整列优先于单项设置。设置属于当前账号的表格视图，不修改业务文字或其他用户的显示。提供 saveState/loadState 才跨刷新保存；无存储接口时只保留在本页面。

升级应用时，必须让视图存储完整保留 links 字段，验证回读；有白名单的后端需显式加入此字段。不要声称旧适配器已支持新状态。createControls 只管理排序等控件，自定义业务行需显式调用新增的 linkNode/urlHref 并接上本应用的偏好编辑；不能仅换包就宣称复杂 CRM 行已自动支持。


## 2.0 接入
先读 API.md 的2.0段落。数组保存用户选择顺序，默认按首项排序。编辑模式与删除权限独立；通过回调接入后端，不假设组件自带数据库。运行 feature-example.html（全虚构）验证选项新增删除、日期和记录删除。旧项目固定版本必须主动升级并检查业务适配。