时间戳

首页 > 解决方案 > 何时更喜欢通过状态与 T 本身

android-jetpack-compose - 何时更喜欢通过状态与 T 本身

问题描述

在任何情况下，人们应该更喜欢这些选择中的一种而不是另一种吗？

@Composable
fun <T> Foo(data: State<T>) { ... }

相比

@Composable
fun <T> Foo(data: T) { ... }

或者对于可变状态，

@Composable
fun <T> Foo(data: MutableState<T>) { ... }

相比

@Composable
fun <T> Foo(data: T, setData: (T) -> Unit) { ... }

显然，拥有 setData lambda 的一个优点是您可以拦截 set 操作，但从 Compose 的角度来看，我更感兴趣。对 compose 编译器或重组将如何工作有任何影响吗？

标签： android-jetpack-compose

解决方案

我会比较喜欢

@Composable
fun <T> Foo(data: T) { ... }

和

@Composable
fun <T> Foo(data: T, setData: (T) -> Unit) { ... }

在他们各自的柜台上。原因是：

  • 对于第一个，如果您State将来必须更改数据结构，则必须Composable无缘无故地重构所有内容，因为State<T>不会为您的Composable. 此外，在谷歌的示例项目和现场演示中，我一直看到他们使用T
  • 对于第二个，假设您正在使用MutableState两个或多个可组合项，例如ComposableA和，如果他们进行任何可能在某些情况下产生问题的ComposableB更新，那么这两个可组合项都可以改变彼此的状态。MutableState如果ComposableP是他们最不常见的父级，我宁愿MutableState在父级中声明并将T和回调传递给ComposableAand ComposableB。你可以比较一下State Hoisting

推荐阅读