性能优化与最佳实践

neq_assign

当组件从它的父组件接收 props 时，change 方法将被调用。除了允许你更新组件的状态，还允许你返回一个布尔类型的值 ShouldRender 来指示组件是否应该响应 props 的更改而重新渲染自身。

重新渲染的开销很大，你应该尽量避免。一个通用的法则是，你只应该在 props 实际更改时重新渲染。以下代码块展示了此法则，如果 props 和先前的 props 不同，则返回 true：

  1. fn change(&mut self, props: Self::Properties) -> ShouldRender {
  2.     if self.props != &props {
  3.         *self.props = props;
  4.         true
  5.     } else {
  6.         false
  7.     }
  8. }

但是我们可以更进一步！对于任何实现了 PartialEq 的项，可以使用一个 trait 和一个 blanket implementation 将这六行样板代码减少到一行。

{% code title=”neq_assign.rs” %}

  1. pub trait NeqAssign {
  2.     fn neq_assign(&mut self, new: Self) -> ShouldRender;
  3. }
  4. impl<T: PartialEq> NeqAssign for T {
  5.     fn neq_assign(&mut self, new: T) -> ShouldRender {
  6.         if self != &new {
  7.             *self = new;
  8.             true
  9.         } else {
  10.             false
  11.         }
  12.     }
  13. }
  15. // ...
  16. fn change(&mut self, props: Self::Properties) -> ShouldRender {
  17.     self.props.neq_assign(props)
  18. }

{% endcode %}

该 trait 称为 NeqAssign 是因为如果目标值和新值不相等，它将赋为新值。

这比简单的实现还要短：

  1. // 不要这样做，除非你无法避免。
  2. fn change(&mut self, props: Self::Properties) -> ShouldRender {
  3.     self.props = props;
  4.     true
  5. }

你不仅限在 change 函数中使用它。通常，在 update 函数中执行此操作也是有意义的，尽管性能提升在那里不太明显。

RC

为了避免在重新渲染时为了创建 props 而克隆大块数据，我们可以使用智能指针来只克隆指针。如果在 props 和子组件中使用 Rc<_> 而不是普通未装箱的值，则可以延迟克隆直到需要修改子组件中的数据为止，在该组件中可以使用 Rc::make_mut 来对要更改数据进行克隆和获取可变引用。通过在要修改前不进行克隆，子组件可以在几乎没有性能成本的情况下拒绝与它们在 Component::change 中拥有状态的 props 相同的 props，这与数据本身需要先复制到父级 props 结构体中，然后在子级中进行比较和拒绝的情况相反。

对于不是 Copy 类型的数据，这种优化是最有用的。如果你能轻松地拷贝数据，那么将其放入智能指针中可能是不值得的。对于可以包含大量数据的结构，例如 Vec，HashMap 和 String，这种优化应该是值得的。

如果子组件从不更新组件的值，则这种优化效果最好，如果父组件很少更新组件的值，则效果更好。这使得 Rc<_>s 是包装纯组件属性值的不错选择。

视图函数

出于代码可读性的原因，将 html! 各个部分的代码迁移到他们自己的函数中通常是有意义的，这样就可以避免在深层嵌套的 HTML 中出现代码块向右偏移。

纯组件 / 函数式组件

纯组件是不会修改它们状态的组件，它们仅展示内容和向普通可变组件传递消息。它们与视图函数不同之处在于他们可以使用组件语法（<SomePureComponent />）而不是表达式语法（{some_view_function()}）来在 html! 宏中使用，并且根据它们的实现，它们可以被记忆化 - 使用前面提到的 neq_assign 逻辑来防止因为相同的 props 而重新渲染。

Yew 没有原生支持纯组件或者函数式组件，但是可以通过外部库获取它们。

函数式组件尚不存在，但是从理论上来讲，可以通过使用 proc 宏和标注函数生成纯组件。

Keyed DOM nodes when they arrive

使用 Cargo Workspaces 进行编译速度优化

可以说，使用 Yew 的最大缺点是编译时间长。编译时间似乎与 html! 宏块中的代码量相关。对于较小的项目，这通常不是什么大问题，但是对于跨多个页面的 web 应用程序，将代码拆分为多个 crates 以最大程度地减少编译器要做的工作通常是有意义的。

你应该尝试让主 crate 处理路由和页面选择，将所有公用的代码移动到另一个 crate，然后为每一个页面创建一个不同的 crate，其中每个页面可能是一个不同的组件，或者只是一个产生 Html 的大函数。在最好的情况下，你将从重新构建所有代码到只重新构建主 crate 和一个页面的 crate。在最糟糕的情况下，当你在“公共” crate 中编辑内容时，你将回到起点：编译所有依赖此公用 crate 的代码，这可能就是除此之外的所有代码。

如果你的主 crate 过于庞大，或者你想在深层嵌套的页面（例如，在另一个页面顶部渲染的页面）中快速迭代，则可以使用一个示例 crate 创建一个更简单的主页面实现并在之上渲染你正在开发的组件。