최근에 compose로만 코드를 짜다가, editText가 특별한 놈인걸 까먹고 있었습니다.
EditText는 자체적으로 StateFul한 녀석이라, Viewmodel에서 상태를 관리하기가 어려운데요.

compose에서는 비동기에 대한 이슈때문에 따로 상태효과를 관리하라는 문서까지 적혀있습니다.
If your TextField state requires business logic validations as you type, it is correct to hoist the state to your ViewModel. If it doesn’t, you can use Composables or a state holder class as the source of truth. To learn more about where to hoist your state you can check the state hoisting documentation.
TextField 상태에서 입력할 때 비즈니스 로직 검증이 필요한 경우 해당 상태를 ViewModel로 올리는 것이 좋습니다. 그렇지 않은 경우 Composable 내부 혹은 State Holder Class(View StateHolder를 얘기합니다.). 상태 호이스트 위치에 대한 자세한 내용은 상태 호이스트 문서를 참조하십시오.
Compose에서는 TextField의 값이 비즈니스 로직과 연관이 없을경우,
View StateHolder에 두는것이 올바르다고 적혀있습니다.
XML에서도 EditText의 값을 Viewmodel에서 관리하기는 이상한데요.
일단 editText의 값이 configuration change에서도 생존하기 때문입니다.
그리고 또한 자체적으로 State를 포함하고 있습니다.

요즘 추세는 복잡한 state을 하나의 클래스로 만들어 관리하는것(sealed class라던가, data class라던가)입니다.
그런데 과연 EditText값까지 필요한것일까요?
editText에 리스너를 달고, viewmodel을 통해 observing 하면 아래와 같은 현상이 보여집니다.
제 생각에는 위와 같이 컴포즈처럼 단순한 UI validation의 경우 UI에서 처리하고,
textField의 변화에 따라 발생하는 비즈니스 로직(실시간 검색 혹은 실시간 닉네임 중복)이 있을때 아래와 같이 처리하면 될것 같습니다.
observe{
lifecycle.repeatOnLifecycle(Lifecycle.State.CREATED) {
profileViewModel.profileStateFlow.collectLatest {
//값이 다를때만 업데이트
if (binding.tietNickname.text.toString() != profileText) setUserProfileNickName(profileText)
}
하지만 곰곰히 생각해보니 addTextChangedListener{}를 통해서 처리하는게 좀더
편하지 않을까 생각됩니다.
Compose에서 view의 stateholder와 business logic의 stateholder를 나누다보니
한번 푹 빠지고 나선 XML에서도 과연 어떻게 관리해야할지 가끔 고민을 하곤합니다.
좋은 글 감사합니다!