把两千行列表页拆成五块：状态该放哪儿

做后台管理页面时最容易写坏的不是复杂交互，是列表页。一个列表页往往要同时处理后端分页、前端筛选、排序、批量选择、刷新后状态保持、以及空态与加载态的切换，每一项单独都不难，堆在一起就会长出两千行组件。我们最近把一个两千三百行的列表页拆开，过程记在这里。第一步是先分清哪些状态属于查询、哪些属于界面。查询状态包括页码、每页条数、排序字段、排序方向、以及全部筛选条件，它们的共同特点是变了就要重新请求；界面状态包括列宽、展开的详情行、批量勾选的集合、当前悬停行，它们变了不该触发请求。这一步不分清，后面所有优化都会打架。第二步是把查询状态整体放进 URL。页码、筛选、排序全部序列化到 query string，好处有三个：刷新不丢、可以直接分享给同事复现问题、浏览器前进后退天然可用。实现上不需要额外状态库，监听地址变化反序列化成查询对象即可。第三步是把请求层收成一个函数。列表页里最常见的错误是同一个组件里出现五处各自封装的请求代码，参数拼接方式各不相同，改一个字段要改五遍。我们收成单个 fetchList(query) 之后，取消请求、超时、错误重试都只写一次。第四步是拆分展示粒度。原来一个组件同时渲染表头、行、分页、批量操作栏，拆成独立子组件后各自只接收自己需要的状态，行组件的重渲染不再牵连分页条。第五步是空态与加载态统一处理。列表为空、筛选无结果、请求失败、加载中，这四种情况以前散落在各处判断，现在由一个状态机统一返回，展示层只负责按状态渲染。整套改完之后组件从两千三百行降到四百行的主逻辑加五个子组件，新增一个列只需要改三处。最直观的收益不是行数，是修 bug 时能快速定位到是哪一层的问题。