[번역] Stateful vs Stateless Composables

해당 글은 https://newsletter.jorgecastillo.dev/p/stateful-vs-stateless-composables 의 번역본입니다.

Stateful vs Stateless Composables

 

해당 포스트는 Jetpack Compose and internals course 에서 "State" 주제를 가져와서 짧게 소개하는 포스트 입니다. 링크에서 전체 개요에 대해 알아보세요

 

In View world  (뷰 시스템)

Compose 전에는 대부분 ViewModel, Presenter, Controller 등을 Activity, Fragment 와 같은 최상단 루트에서 정의해서 사용했었습니다. 해당 방식을 통해 UI 로직과 비즈니스 로직을 분리해서 처리할 수 있었습니다. 가령 UI state 일부분만 보여주고, 콜백을 통해 이벤트를 공지하는식으로 처리해서 뷰모델이 최상단에서 상태를 관리 할 수 있도록 처리했습니다.

 

뷰모델을 트리 아래로 보내지 않음으로써(뷰모델을 뷰에 파라미터로 넘기지 않는다는 이야기 입니다. 그래야 뷰모델에 대한 의존성이 없어져서 재활용 가능하게 됩니다.) 전반적으로 뷰의 재사용성을 높이고, UI 상호작용과, 행동의 테스트를 용이하게 만들었습니다. (Android 의존성으로 부터 분리)

 

In Compose world (컴포즈 시스템)

컴포즈도 크게 다르지 않습니다. 목표는 Composable 의 Stateless 를 유지하는 것 입니다. 물론 한가지 예외가 있습니다. 당연하게도 루트 레벨 입니다. (루트 레벨은 뷰모델 등에서 UI state 를 가지고 있을 것이라 Statefull 합니다) 아래 이미지를 보면 SpeakerScreen 에 statefull 이라 적혀있네요 :)

 

아래와 같이 나눠볼 수 있습니다.

 

Stateful 🤓

• 자신의 상태를 생성하고 관리합니다
• 호출하는 쪽에서 상태를 관리할 필요가 없을 때 사용 합니다(정적인 뷰 등)
• 재사용할 필요 없을 때 사용합니다
• 보통 트리의 상단 부분에서 많이 보입니다. (상단에서 상태를 가지고 하위에 데이터를 전달해주기 때문이에요)

Stateless 🤷‍♂️

• 자신의 상태를 호이스팅 합니다. (호출하는 쪽에서 상태를 내려줍니다. - 바보 뷰 만들기) 
• 재사용해야하는 경우 사용합니다.
• 값을 공유 하거나, 가로채거나, 분리할 수 있도록 합니다.

이야기 하려는 부분은 어떤식으로든 뷰모델을 트리 아래로 전달 하지 않음으로써, stateless composable 의 장점을 온전히 가지고, 고립시켜서 테스트를 쉽게 만들어야 한다는 점입니다. 

 

Fragment 를 활용중이라면 해당 클래스에 ViewModel 을 넣어두고 이후에 Composable tree 에는 stateless 하게 만들 수 있습니다.

 

그럼 20000-