最佳开发实践

使用 Dojo 部件时，应谨记一些重要原则，以避免在应用程序代码中引入反模式。试图以不受支持的方式使用框架可能会导致意外的行为，并在应用程序中引入难以发现的错误。

部件属性

• 部件应只能读取传入其中的属性(properties)。
  • 如果修改了传入部件中的属性值，则不能回传给框架，以避免导致部件和框架之间出现差异。
• 部件应避免基于属性进一步派生渲染状态，而是完全依赖于向其提供的渲染状态。
  • 与修改接收到的属性一样，派生渲染状态也会导致部件与框架之间产生类似的歧义；框架无从得知派生出的状态，所以无法正确判断部件何时更新，从而需要让部件失效并重新渲染。
• 如果需要，内部或私有状态可以完全封装在部件内。
  • 实现“纯”部件是一个有效且通常是可取的模式，它不会产生副作用，并用属性接收它们的所有状态，但这不是开发 Dojo 部件的唯一模式。

使用基于类的部件

• __render__, __setProperties__, and __setChildren__ 函数属于框架内部实现细节，绝不允许在应用程序中调用或覆写。
• 应用程序不应直接实例化部件——Dojo 完全接管部件实例的生命周期，包括实例化、缓存和销毁。

虚拟 DOM

• 虚拟节点的 key 应在多次渲染调用中保持一致。
  • 如果在每次渲染调用中都指定一个不同的 key，则 Dojo 无法有效地将前一次渲染和本次渲染中的相同节点关联上。Dojo 会将上一次渲染中没有看到的新 key 当作新元素，这会导致从 DOM 中删除之前的节点并重新添加一套，即使属性没有发生变化，不需要重新更新 DOM。
  • 一个常见的反模式是在部件的渲染函数中为节点的 key 分配一个随机生成的 ID（如 GUID 或 UUID）。除非生成策略是等幂的，否则不应在渲染函数中生成节点的 key 值。
• 应用程序不应存储虚拟节点的引用，以便从部件的渲染函数返回它们后，进行后续操作；也不应尝试通过使用单个实例跨多个渲染调用来优化内存分配。
  • 虚拟节点被设计成轻量级的，并且在每次部件渲染周期内实例化新版本的开销非常低。
  • 框架依赖于在两次部件渲染函数调用中有两个单独的虚拟节点实例来执行准确的更改检测。如果未检测到任何变化，则不会产生进一步的开销、渲染等。

渲染到 DOM 中

• 应用程序不应使用命令式的 DOM 操作调用。
  • 框架负责处理所有具体的渲染职责，并且为部件作者提供了替代机制，以更简单、类型安全和响应式的方式使用各种 DOM 功能。