菜单

最佳实践开发

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

小部件应将传递给它们的属性视为只读。
- 在小部件内对接收到的属性所做的更改无法传播回框架，并会导致小部件和框架之间出现差异。
小部件应避免从其属性中推导出进一步的渲染状态，而应依赖于提供给它们的完整渲染状态。
- 推导出渲染状态会导致类似于修改接收到的属性那样的小部件和框架之间的差异；框架不知道推导出的状态，因此无法正确确定何时更新了小部件并需要失效和重新渲染。
如果需要，内部或私有状态可以完全封装在小部件内。
- 实现不产生副作用并接收其所有状态作为属性的“纯”小部件是一个有效且通常是可取的模式，但这并不是 Dojo 小部件开发中的唯一模式。

使用基于类的小部件

__render__、__setProperties__ 和 __setChildren__ 函数是框架内部实现细节，永远不应该在应用程序代码中调用或覆盖。
应用程序不应该直接实例化小部件 - Dojo 完全管理小部件实例的生命周期，包括实例化、缓存和销毁。

虚拟 DOM

虚拟节点 key 应该在多个渲染调用中保持一致。
- 如果在每次渲染调用中指定不同的 key，Dojo 无法有效地在先前和当前渲染之间关联节点。Dojo 将它在先前渲染中未见过的新的 key 视为新元素，这会导致先前节点从 DOM 中删除，并添加一组全新的节点 - 即使没有其他属性更改实际上需要 DOM 更新。
- 一个常见反模式是在小部件的渲染函数中将随机生成的 ID（例如 GUID 或 UUID）分配为节点的 key。节点 key 不应该在渲染函数中生成，除非生成策略是幂等的。
应用程序不应该存储对虚拟节点的引用以供稍后在返回它们的小部件渲染函数之外进行操作，也不应该尝试通过在多个渲染调用中使用单个实例来优化内存分配。
- 虚拟节点旨在轻量级，并且在每个小部件渲染周期内实例化新版本所需的成本非常低。
- 框架依赖于在两次小部件渲染函数调用中拥有两个独立的虚拟节点实例来执行准确的更改检测。如果未检测到更改，则不会产生进一步的成本，包括渲染或其他成本。

渲染和 DOM

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