Ember CLI 中 @tracked 属性数组操作的最佳实践

在 Ember.js 开发中，使用 @tracked 装饰器来管理响应式数据是常见的做法。然而，当开发者尝试在 @tracked 修饰的数组属性上调用 pushObject 方法时，可能会遇到"pushObject is not defined"的错误。本文将深入解析这一现象背后的原因，并提供现代 Ember 开发中的正确解决方案。

问题本质分析

这个问题的根源在于 Ember.js 对数组原型扩展(Array Prototype Extensions)的处理方式变化。在早期版本的 Ember 中，框架会自动为数组添加一些便捷方法，如 pushObject、removeObject 等。这些方法通过修改 JavaScript 原生数组的原型来实现。

然而，随着 JavaScript 生态的发展，这种修改原生原型的做法被认为是不良实践，因为它可能导致：

1. 与其他库的潜在冲突
2. 代码行为难以预测
3. 维护困难

因此，Ember 团队决定逐步弃用这种模式，转而推荐使用更标准的 JavaScript 数组操作方法。

现代解决方案

在 Ember Octane 及后续版本中，推荐的做法是：

1. 使用标准 JavaScript 数组方法
2. 结合 @tracked 装饰器确保响应性

正确使用方式

import { tracked } from '@glimmer/tracking';
import { action } from '@ember/object';

class MyComponent {
  @tracked items = [];

  @action
  addItem(newItem) {
    // 使用标准数组方法
    this.items = [...this.items, newItem];
    
    // 或者使用 push 方法配合数组解构
    // this.items = this.items.concat([newItem]);
  }
}

为什么这种方式有效

@tracked 装饰器会跟踪属性的重新赋值操作。当我们使用展开运算符(...)或 concat 方法创建新数组并重新赋值时，@tracked 能够检测到这一变化并触发相应的重新渲染。

迁移建议

对于现有代码库的迁移，建议：

1. 逐步替换所有 pushObject 调用
2. 考虑使用 Ember 提供的 ArrayProxy 等工具类（如果需要保留旧有行为）
3. 在模板中，可以直接使用标准数组方法如 push/pop 等

性能考虑

虽然创建新数组看起来可能比直接修改原数组性能稍差，但实际上：

1. 现代 JavaScript 引擎对这类操作有很好的优化
2. 不可变数据模式带来的可预测性优势通常超过微小的性能开销
3. Ember 的响应式系统能够高效处理这类变更

总结

Ember 社区正在向更标准的 JavaScript 实践靠拢，弃用数组原型扩展是这一趋势的一部分。开发者应该适应使用标准数组方法配合 @tracked 装饰器来管理响应式数组数据。这种模式不仅更符合现代 JavaScript 实践，还能带来更好的代码可维护性和可预测性。