UI가 유저에게 표시되는 것을 말한다면, UI State는 앱이 유저에게 무엇을 보여줘야 하는지를 나타내는 것입니다.
UI 요소인 Compose와 UI State를 결합해야 비로소 유저에게 보이기 위한 UI가 완성됩니다.
XML에서는 LiveData와 observe, StateFlow와 repeatOnLifecycle, 등을 생명주기게 맞춰서 UI 요소와 UI State를 결합하고 상태를 유지했습니다.
그렇다면 Compose에서는 어떻게 할까요?
XML에서 Activity, Fragment의 생명주기를 따랐다면, Compose는 State의 변화에 따른 Recomposition(재구성)이 있습니다.
Recomposition이 일어나면 composable들을 다시 실행하여, 재구성을 통해 UI를 업데이트 합니다.
하지만 stateful한 데이터를 가지고 있는 composable에서 재구성이 일어나면, 해당 데이터는 그에 따라 사라지게 됩니다.
이를 위해, Android에서는 Compose의 생명주기에 맞춰 데이터를 유지할 수 있는 api인 remember를 제공하고 있습니다.
remember란? composable에서 객체를 메모리에 저장할 수 있는 api function입니다.
remember는 초기 Composition에서 값을 저장하고, 재구성이 될 때 저장된 값(이전 상태)를 반환하여 state를 일관되게 유지할 수 있도록 해줍니다.
그리고 해당 composable이 Composition에서 제거되면, 저장된 값은 지워집니다.
내부 상태를 저장하기 위해 remember를 사용하면, composable이 stateful하게 됩니다.
이는 외부에서 composable에 접근하는 것을 제한하기 때문에, 재사용하기 어렵고 테스트를 어렵게 만듭니다.
이를 위해, Compose에서는 State를 위한 여러 API를 제공하고 있습니다.
그렇다면 무조건 stateless한 composable이 좋은걸까요?
이는 캡슐화와 연관되어 있다고 생각합니다.
관심사에 따라, 상태를 외부에서 수정할 필요가 없다면 stateful한 상태로 두어도 좋습니다. 불필요한 개방은 오히려 가독성과 재사용성을 떨어뜨릴 수 있습니다.
상황과 관심사, 활용도 등등 여러가지를 고려하여 remember와 MutableState, State를 활용하는 것이 좋습니다.