Expensify/App 客户端违规显示逻辑优化方案

背景介绍

在Expensify/App项目中，系统会检测并显示各种违规行为（Violations），如重复交易、自动拒绝费用等。这些违规信息需要根据不同用户角色和权限进行差异化显示。当前实现存在性能问题和技术债务，需要重构优化。

现有问题分析

当前系统存在以下技术痛点：

1. 后端差异化计算：违规信息在后端根据不同用户单独计算，导致相同违规需要为不同用户重复计算
2. 低效通信机制：需要为每个用户单独发送Onyx更新，违反"不要为不同用户发送略有差异的更新"的最佳实践
3. 逻辑分散：违规可见性判断逻辑分散在后端，客户端无法灵活控制

技术解决方案

核心思路转变

将违规信息的过滤逻辑从后端迁移到客户端，后端统一计算所有可能的违规，由客户端根据用户角色和上下文决定是否显示。

关键实现细节

1. 违规驳回状态存储：

   • 使用交易记录的nameValuePairs字段存储驳回状态
   • 数据结构示例：

     {
       "dismissedViolations": {
         "duplicatedTransaction": {
           "[e-mail]": 1748905104132286
         }
       }
     }
     

   • 键为违规类型，值为用户邮箱与驳回时间戳的映射

2. 客户端过滤规则：

   • 自动拒绝费用违规：
     • 显示给：报告提交者 或 工作区管理员(当报告处于开放状态时)
   • 超过自动审批限额：
     • 仅显示给：工作区管理员(提交者无操作权限)
   • RTER违规：
     • 显示给：报告提交者 或 非即时提交的工作区
   • 非智能扫描收据：
     • 显示条件需同时满足：
       1. 用户有工作区访问权限
       2. 用户不是提交者
       3. 用户不是工作区管理员或报告未开放

3. 混合应用兼容：

   • 方案需同时支持NewDot和Classic两种界面风格
   • 保持行为一致性，确保两种界面显示相同的违规信息

技术优势

1. 性能提升：

   • 减少后端计算量，避免为不同用户重复计算相同违规
   • 使用报告级Onyx通道广播更新，替代账户级通道

2. 架构优化：

   • 将业务逻辑集中到客户端，符合现代前端架构趋势
   • 减少前后端耦合，提高系统可维护性

3. 用户体验一致：

   • 确保所有客户端显示相同的违规信息
   • 支持实时更新，提升协作效率

实施注意事项

1. 测试策略：

   • 需模拟后端返回所有违规的场景
   • 验证各类型违规在不同用户角色下的显示/隐藏行为
   • 覆盖NewDot和Classic两种界面

2. 数据兼容：

   • 保持与现有驳回状态存储格式的兼容
   • 确保迁移过程中不丢失用户已驳回的违规记录

3. 性能监控：

   • 实施后需监控客户端渲染性能
   • 特别关注大型工作区或含多违规报告的场景

总结

该优化方案通过将违规过滤逻辑迁移到客户端，解决了现有架构中的性能瓶颈和代码维护问题。新设计遵循了"计算一次，广播所有"的原则，同时保持了灵活的用户级显示控制，为Expensify/App的违规处理系统奠定了更可持续的技术基础。