<div id="readability-page-1" class="page"><div><div tabindex="-1" aria-hidden="false" role="tooltip"><a rel="noopener follow" href="/@hongbeomi?source=post_page---byline--6abd1eca4e25---------------------------------------" data-discover="true"><div><img alt="hongbeom" src="https://miro.medium.com/v2/resize:fill:64:64/1*Mok6UmeBD0xatCqaYrkAUQ.png" width="32" height="32" loading="lazy" data-testid="authorPhoto"></div></a></div><figure><div role="button" tabindex="0">Zoom image will be displayed</div><figcaption>Photo by <a href="https://unsplash.com/@kasiade?utm_source=medium&amp;utm_medium=referral" rel="noopener ugc nofollow" target="_blank">Kasia Derenda</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral" rel="noopener ugc nofollow" target="_blank">Unsplash</a></figcaption></figure>Compose에서 UI 상태를 관리하는 것은 매우 중요합니다. 우리는 상태에 따라 유저에게 올바른 UI를 표시하기 위해 상태를 적절하게 모델링하고, 보관해야 합니다. 상태를 적절하게 관리하지 못할 경우 UI가 지나치게 많이 recomposition 되거나 필요한 상황에 올바른 상태를 표시하지 못할 수도 있습니다. 상태를 보관하는 몇 가지 방법에 대해 살펴보고 어느 상황에서 어떤 방식을 사용하는 것이 좋을지 알아보겠습니다.<h2 id="0fc1">ViewModel</h2>가장 많이 쓰이는 상태 보관 방법은 <code>ViewModel</code> 입니다. <code>ViewModel</code>에 보관되어 있는 상태는 Configuration Change 이벤트가 발생해도, <code>ViewModel</code>이 살아있기 때문에 올바르게 상태가 보존될 수 있습니다.또한 <code>SavedStateHandle</code> API를 사용하여 ‘시스템 리소스 부족에 의한 프로세스 종료’ 같은 케이스에도 대응할 수 있습니다.<pre>class XXXViewModel( savedStateHandle: SavedStateHandle ): ViewModel() { var name by savedStateHandle.saveable(stateSaver = TextField.Saver) { mutableStateOf("") } private set // other function.. }</pre>위의 코드에서는 Compose <code>State</code>와 <code>SavedStateHandle</code>의 통합 API인 <code>saveable</code> 함수를 이용하고 있습니다. 물론 <code>Flow</code>도 지원합니다. <code>ViewModel</code>은 비즈니스 로직에서 필요한 상태가 존재하는 경우 보관하기에 알맞습니다.그렇다면 재사용되는 UI 로직과 상태는 어디에 보관하는 것이 좋을까요? 예를 들어, UI의 모습이 다른 몇몇 <code>Composable</code>에서 파라미터로 수신하는 <code>count</code> 값을 업데이트 할 수 있으며 해당 <code>count</code>의 값을 <code>Composable</code> 각각에서 유지해야 하는 상황을 생각해봅시다.해당 <code>Composable</code>들은 아래와 같은 UI 로직을 공통적으로 가지고 있을 것 입니다.<ul><li id="8233">유저의 이벤트를 통해 <code>count</code> 값 업데이트</li><li id="9827"><code>count</code> 값에 따라서 다른 UI를 표시하거나 이벤트 제어</li><li id="eb11">configuration changed 이벤트 이후 <code>count</code> 값 보존</li></ul>위에서 요구되는 상태와 로직을 <code>ViewModel</code>에서 관리한다면 <code>Composable</code> 별로 상태를 각각 보관해야 할 뿐더러 코드가 굉장히 복잡해질 것입니다. 이런 중복되는 UI 로직의 케이스는 어떻게 상태를 관리하면 좋을까요?<h2 id="4109">Local State Holder</h2>우리는 위의 예시로 봤던 <code>count</code> 의 로직과 상태를 StateHolder 클래스를 구현하여 UI 로직과 상태의 재사용성을 높이고 코드 중복을 줄일 수 있습니다.<pre>// State Holder class CountState(initialCount: Int) { var count by mutableIntStateOf(initialCount) private set // count 값에 따른 이벤트 발생을 위한 프로퍼티 val canXXX: Boolean get() = count &gt; 0 fun plus(value: Int) { count += value } fun minus(value: Int) { count -= value } // other function.. }</pre>Compose에서는 상태 보존을 위한 <code><a href="https://androidx.tech/artifacts/compose.runtime/runtime-saveable-android/1.5.0-source/commonMain/androidx/compose/runtime/saveable/RememberSaveable.kt.html" rel="noopener ugc nofollow" target="_blank">rememberSavable</a></code> API를 제공하기에 이 API를 사용하여 상태를 안전하게 보존할 수 있습니다. 이를 위해 Custom한 <code>Saver</code> 객체를 구현하여 제공해야 합니다.<pre>class CountState(initialCount: Int) { ... companion object { val Saver: Saver&lt;CountStateHolder, Int&gt; = Saver( save = { it.count }, restore = { CountStateHolder(it) } ) } }@Composable fun rememberCountState( initialCount: Int = 0, ): CountState = rememberSaveable(saver = CountStateHolder.Saver) { CountState(initialCount) }// using @Composable fun AComponent( count: Int, // ... ) { val countState = rememberCountState(count) // ... }@Composable fun BComponent( count: Int, // ... ) { val countState = rememberCountState(count) // ... }</pre><code><a href="https://androidx.tech/artifacts/compose.runtime/runtime-saveable/1.6.6-source/commonMain/androidx/compose/runtime/saveable/Saver.kt.html" rel="noopener ugc nofollow" target="_blank">Saver</a></code> 객체는 <code>LocalSaveableStateRegistry</code>에 접근하여 save 및 restore를 실행하는데, 기본적으로 우리가 <code>rememberSaveable</code> 함수를 사용할 때 별다른 <code>Saver</code> 의 구현 없이 값을 저장할 수 있는 타입은 아래와 같습니다. (<code><a href="https://androidx.tech/artifacts/compose.ui/ui/1.0.0-beta05-source/androidx/compose/ui/platform/DisposableSaveableStateRegistry.android.kt.html" rel="noopener ugc nofollow" target="_blank">DisposableSaveableStateRegistry.android.kt</a></code> 참조)<ul><li id="4580">Serializable(<code>Arrays</code>, <code>ArrayList</code>, <code>Primitives</code>, <code>Bundle</code>)</li><li id="b262">Parcelable</li><li id="db50">String</li><li id="6d28">SparseArray</li><li id="6210">Binder</li><li id="025f">Size</li><li id="e3a9">SizeF</li></ul>위 타입을 제외한 나머지 타입을 저장하려면 Custom <code>Saver</code> 객체를 제공해야 합니다.위처럼 StateHolder 클래스를 직접 구현하면, UI 로직과 상태를 재사용하기 용이하고 중복된 코드가 줄어들며 테스트 코드 작성도 쉽게 가능합니다. 이런 방식의 상태 관리는 디자인 시스템 컴포넌트를 구성해야할 때도 빛을 발할 수 있습니다. 일관된 UI 로직과 상태가 포함된 베이스 컴포저블을 작성한 뒤, 해당 컴포저블을 래핑한 컴포저블을 작성할 수 있습니다.위에서 살펴본 <code>CountState</code> 상태를 보유한 베이스 컴포저블이 있다고 가정해보겠습니다.<pre>@Composable fun Counter( modifier: Modifier = Modifier, state: CountState = rememberCountState(), //... ) { Text( modifier = modifier, text = state.count.toString(), //... ) }@Composable fun CounterWithIcon( modifier: Modifier = Modifier, state: CountState = rememberCountState(), icon: @Composable () -&gt; Unit, //... ) { // ui component 구성 }</pre>이 경우에도 재사용성 높은 컴포넌트를 쉽게 구성할 수 있음을 확인할 수 있습니다.어떤 상태 보관 방식 전략을 취하느냐에 따라 코드 재사용성과 중복성이 달라질 수 있기에 잘 이해하고 사용하는 것이 중요한 것 같습니다. 실제로 실무에서도 컴포즈를 사용하는 경우 다양한 상태를 관리하게 될 텐데, UI 로직인지 비즈니스 로직인지에 따라 전략을 잘 수립하여 관리하는 것이 좋겠습니다.<h2 id="6eb0">참조</h2><ul><li id="f891"><a href="https://www.youtube.com/watch?v=V-s4z7B_Gnc" rel="noopener ugc nofollow" target="_blank">https://www.youtube.com/watch?v=V-s4z7B_Gnc</a></li></ul></div></div>

Stories by hongbeom on Medium

Compose StateHolder 1— State Holder를 통해 효율적으로 State 관리하기
Compose에서 UI 상태를 관리하는 것은 매우 중요합니다. 우리는 상태에 따라 유저에게 올바른 UI를 표시하기 위해 상태를 적절하게 모델링하고, 보관해야 합니다. 상태를 적절하게 관리하지 못할 경우 UI가 지나치게 많이 recomposition 되거나 필요한 상황에 올바른 상태를 표시하지 못할 수도 있습니다. 상태를 보관하는 몇 가지 방법에 대해 살펴보고 어느 상황에서 어떤 방식을 사용하는 것이 좋을지 알아보겠습니다.
ViewModel
가장 많이 쓰이는 상태 보관 방법은 ViewModel 입니다. ViewModel에 보관되어 있는 상태는 Configuration Change 이벤트가 발생해도, ViewModel이 살아있기 때문에 올바르게 상태가 보존될 수 있습니다.
또한 SavedStateHandle API를 사용하여 ‘시스템 리소스 부족에 의한 프로세스 종료’ 같은 케이스에도 대응할 수 있습니다.
class XXXViewModel(
 savedStateHandle: SavedStateHandle
): ViewModel() {
 var name by savedStateHandle.saveable(stateSaver = TextField.Saver) {
 mutableStateOf("")
 }
 private set
 
 // other function..
}
위의 코드에서는 Compose State와 SavedStateHandle의 통합 API인 saveable 함수를 이용하고 있습니다. 물론 Flow도 지원합니다. ViewModel은 비즈니스 로직에서 필요한 상태가 존재하는 경우 보관하기에 알맞습니다.
그렇다면 재사용되는 UI 로직과 상태는 어디에 보관하는 것이 좋을까요? 예를 들어, UI의 모습이 다른 몇몇 Composable에서 파라미터로 수신하는 count 값을 업데이트 할 수 있으며 해당 count의 값을 Composable 각각에서 유지해야 하는 상황을 생각해봅시다.
해당 Composable들은 아래와 같은 UI 로직을 공통적으로 가지고 있을 것 입니다.
유저의 이벤트를 통해 count 값 업데이트
count 값에 따라서 다른 UI를 표시하거나 이벤트 제어
configuration changed 이벤트 이후 count 값 보존
위에서 요구되는 상태와 로직을 ViewModel에서 관리한다면 Composable 별로 상태를 각각 보관해야 할 뿐더러 코드가 굉장히 복잡해질 것입니다. 이런 중복되는 UI 로직의 케이스는 어떻게 상태를 관리하면 좋을까요?
Local State Holder
우리는 위의 예시로 봤던 count 의 로직과 상태를 StateHolder 클래스를 구현하여 UI 로직과 상태의 재사용성을 높이고 코드 중복을 줄일 수 있습니다.
// State Holder
class CountState(initialCount: Int) {
 var count by mutableIntStateOf(initialCount)
 private set
 // count 값에 따른 이벤트 발생을 위한 프로퍼티
 val canXXX: Boolean
 get() = count > 0
 
 fun plus(value: Int) {
 count += value
 }
 fun minus(value: Int) {
 count -= value
 }
 // other function..
}
Compose에서는 상태 보존을 위한 rememberSavable API를 제공하기에 이 API를 사용하여 상태를 안전하게 보존할 수 있습니다. 이를 위해 Custom한 Saver 객체를 구현하여 제공해야 합니다.
class CountState(initialCount: Int) {
 ...
 companion object {
 val Saver: Saver<CountStateHolder, Int> = Saver(
 save = { it.count },
 restore = { CountStateHolder(it) }
 )
 }
}
@Composable
fun rememberCountState(
 initialCount: Int = 0,
): CountState = rememberSaveable(saver = CountStateHolder.Saver) {
 CountState(initialCount)
}
// using
@Composable
fun AComponent(
 count: Int,
 // ...
) {
 val countState = rememberCountState(count)
 // ...
}
@Composable
fun BComponent(
 count: Int,
 // ...
) {
 val countState = rememberCountState(count)
 // ...
}
Saver 객체는 LocalSaveableStateRegistry에 접근하여 save 및 restore를 실행하는데, 기본적으로 우리가 rememberSaveable 함수를 사용할 때 별다른 Saver 의 구현 없이 값을 저장할 수 있는 타입은 아래와 같습니다. (DisposableSaveableStateRegistry.android.kt 참조)
Serializable(Arrays, ArrayList, Primitives, Bundle)
Parcelable
String
SparseArray
Binder
Size
SizeF
위 타입을 제외한 나머지 타입을 저장하려면 Custom Saver 객체를 제공해야 합니다.
위처럼 StateHolder 클래스를 직접 구현하면, UI 로직과 상태를 재사용하기 용이하고 중복된 코드가 줄어들며 테스트 코드 작성도 쉽게 가능합니다. 이런 방식의 상태 관리는 디자인 시스템 컴포넌트를 구성해야할 때도 빛을 발할 수 있습니다. 일관된 UI 로직과 상태가 포함된 베이스 컴포저블을 작성한 뒤, 해당 컴포저블을 래핑한 컴포저블을 작성할 수 있습니다.
위에서 살펴본 CountState 상태를 보유한 베이스 컴포저블이 있다고 가정해보겠습니다.
@Composable
fun Counter(
 modifier: Modifier = Modifier,
 state: CountState = rememberCountState(),
 //...
) {
 Text(
 modifier = modifier,
 text = state.count.toString(), 
 //...
 )
}
@Composable
fun CounterWithIcon(
 modifier: Modifier = Modifier,
 state: CountState = rememberCountState(),
 icon: @Composable () -> Unit,
 //...
) {
 // ui component 구성
}
이 경우에도 재사용성 높은 컴포넌트를 쉽게 구성할 수 있음을 확인할 수 있습니다.
어떤 상태 보관 방식 전략을 취하느냐에 따라 코드 재사용성과 중복성이 달라질 수 있기에 잘 이해하고 사용하는 것이 중요한 것 같습니다. 실제로 실무에서도 컴포즈를 사용하는 경우 다양한 상태를 관리하게 될 텐데, UI 로직인지 비즈니스 로직인지에 따라 전략을 잘 수립하여 관리하는 것이 좋겠습니다.
참조
https://www.youtube.com/watch?v=V-s4z7B_Gnc
Compose에서 State Holder를 통해 효율적으로 State 관리하기 was originally published in hongbeomi dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Compose에서 State Holder를 통해 효율적으로 State 관리하기

댓글