<div id="readability-page-1" class="page"><div>이 글을 읽기 전, State와 StateObject에 대한 이해가 필요합니다. State와 StateObject가 무엇인지에 대한 내용은 아래 글을 참고해 주세요!ㅎㅎ
<ul>
<li><a href="https://velog.io/@jwlee010523/SwiftUI-State-Binding">SwiftUI - State와 Binding</a></li>
<li><a href="https://velog.io/@jwlee010523/SwiftUI-StateObject">SwiftUI - StateObject</a></li>
</ul>
<h2 id="state와-stateobject를-어디에서-사용하지">State와 StateObject를 어디에서 사용하지??</h2>
SwiftUI를 사용하다보면 언제 State와 StateObject를 언제 사용해야 하는지 고민 되는 순간이 있습니다. 결론부터 얘기하면 <code>ViewModel은 절대로 State로 선언하면 안됩니다.</code> 반드시 <code>@StateObject</code>와 <code>@ObservedObject</code>를 선언해야 합니다.
왜 그럴까요??
<h3 id="state-는-값-타입-전용이다">@State 는 값 타입 전용이다.</h3>
<code>@State</code>는 값 타입 전용 상태 프로퍼티에 쓰라고 만든 속성이기 때문입니다. <code>ViewModel</code> 처럼 참조 타입(class)을 관리하도록 만들어진 속성이 아닌 것이죠.
<h3 id="state는-상태를-값-복사로-관리한다">@State는 상태를 값 복사로 관리한다.</h3>
<code>@State</code>는 내부적으로 뷰가 상태를 직접 소유하고 재생성합니다. 즉, <code>ViewModel</code> 인스턴스가 뷰의 라이프사이클과 함께 자주 초기화 될 수 있습니다. 그렇게 되면 다음과 같은 문제가 발생합니다.
<ul>
<li><code>ViewModel</code>의 상태가 초기화 된다.</li>
<li>API 호출 재실행된다.</li>
<li><code>@Published</code> 값 변경이 UI에 반영되지 않는다.</li>
</ul>
<h3 id="mvvm-아키텍처를-깨드린다">MVVM 아키텍처를 깨드린다</h3>
또 다른 문제로는 <code>MVVM</code> 아키텍처를 깨뜨리는 것입니다.
<code>MVVM</code>에서 <code>ViewModel</code>은 <code>View</code>에 종속되지 않고, 독립적인 객체로 상태를 관리해야 합니다. 그런데 <code>@State</code>로 선언하면 <code>View</code>가 <code>ViewModel</code>을 직접 “가지고” 있기 때문에 <code>View</code>가 사라질 때마다 <code>ViewModel</code>도 메모리에서 자동으로 해제됩니다. 이는 위에서 언급한데로 <code>ViewModel</code>이 상태를 유지하지 못하게 되고, <code>View</code>에 종속적이게 됩니다. 
즉, <code>View</code>가 사라질 때 <code>ViewModel</code>도 함께 사라지기 때문에 상태 저장 책임이 <code>View</code>로 넘어가게 되어 아키텍처가 흐트러지는 것입니다.
그럼 어떻게 선언해야 할까요? 표로 정리하면 다음과 같습니다.

























<table><thead><tr><th>선언 방식</th><th>언제 쓰나</th><th>특징</th></tr></thead><tbody><tr><td><code>@StateObject</code></td><td>View가 ViewModel의 소유권을 갖는 경우</td><td>View가 처음 만들어질 때 단 한번 생성되고 이후 유지됨</td></tr><tr><td><code>@ObservedObject</code></td><td>ViewModel을 외부에서 주입받는 경우</td><td>부모 뷰나 상위 객체에서 전달받음. ViewModel을 소유하진 않음.</td></tr><tr><td><code>@EnvironmentObject</code></td><td>앱 전체 또는 특정 트리에서 공유하는 경우</td><td>전역 상태 공유용</td></tr></tbody></table>
아래는 가장 일반적인 방식에 대한 예제입니다.
<pre><code>struct SignupView: View {
 @StateObject private var viewModel = SignupViewModel()
 
 var body: some View {
 // 바인딩 사용
 }
}</code></pre>
<h3 id="view가-소유하지만-로직은-viewmodel이-담당">View가 소유하지만, 로직은 ViewModel이 담당</h3>
그럼 여기서 <code>@StateObject</code>도 <code>View</code>가 <code>ViewModel</code>에 대한 소유권을 갖는데, 그럼 이 경우도 <code>ViewModel</code>이 <code>View</code>에 종속 되는 것이 아닌가 하는 의문이 생길 수 있습니다.
여기서 가장 결정적인 차이점이 있는데요.
바로, <code>@StateObject</code>는 뷰가 처음 생성될 때 <code>ViewModel</code>을 단 한번만 초기화 한다는 점입니다. 반면에 <code>@State</code>는 값 복사 기반이라 <code>View</code>가 리렌더링될 때마다 <code>ViewModel</code>이 계속 새로 생성되기 때문인 것입니다.
사실 위에서 계속 언급해왔던 사실이죠. 
정리하면, <code>@State</code>와 <code>@StateObject</code>는 둘 다 <code>View</code>가 <code>ViewModel</code>을 소유하는 것은 맞지만 <code>@State</code>는 렌더링 될 때마다 계속 생성이 되고, <code>@StateObject</code>는 뷰 생성 시 한번만 초기화 되는 것입니다. 즉, <code>MVVM</code>에서는 <code>ViewModel</code>이 <code>View</code>에 소유되는 것 자체가 문제가 아니라 상태를 간접적으로 업데이트를 “지속적”으로 할 수 있느냐가 더 중요한 관점인 것입니다.
또한, <code>@StateObject</code>로 선언함으로써 <code>ViewModel</code>이 <code>View</code>의 생명주기에 따라 존재할 뿐, <code>View</code>가 <code>ViewModel</code>의 로직을 직접 다루거나, 상태를 바꾸지는 않습니다. 이렇게 함으로써 생성 책임은 <code>View</code>가 가져갈 수 있지만, “로직 책임”은 <code>ViewModel</code>이 하게 되어 역할을 명확히 분리할 수 있게 되는 것이죠.
<h3 id="mvvm을-깨는-예시">MVVM을 깨는 예시</h3>
그렇다면 MVVM을 깨는 구조는 어떤 것이 있을까요? 
<ol>
<li>
View에서 상태를 직접 가짐
<pre><code>// 뷰에서 프로퍼티 값을 수정 및 저장
@State var email = ""</code></pre>
</li>
<li>
ViewModel 없이 API 호출이나 유효성 검사 직접 처리
<pre><code>// 뷰에서 직접 유효성 검사 처리
if email.contains("@") { ... }</code></pre>
</li>
<li>
View가 ViewModel의 내부 상태를 바꾸는 등 로직 침범
</li>
</ol>
SwiftUI에서 상태를 선언할 때 가장 중요한 것은 ‘누가 상태를 소유하고, 누가 그것을 관리하는가’입니다.
<code>@StateObject</code>는 <code>View</code>가 <code>ViewModel</code>을 “소유”하되, 로직에는 “침범”하지 않기 때문에 <code>MVVM</code> 원칙을 지키는 것입니다. 반면, <code>@State</code>는 값 타입에 적합한 속성으로, <code>ViewModel</code>처럼 참조 타입인 객체에는 절대 사용해서는 안 됩니다.
따라서 <code>ViewModel</code>은 항상 <code>@StateObject</code> 또는 <code>@ObservedObject</code>로 관리하고, <code>@State</code>는 값 타입의 간단한 <code>View </code>내부 상태에만 사용하는 것이 좋습니다.
<blockquote>
출처 
<a href="https://developer.apple.com/documentation/swiftui/state">https://developer.apple.com/documentation/swiftui/state</a> 
<a href="https://developer.apple.com/documentation/swiftui/stateobject">https://developer.apple.com/documentation/swiftui/stateobject</a> 
<a href="https://www.dhiwise.com/post/swiftui-state-vs-stateobject-how-they-differ-in-usage">https://www.dhiwise.com/post/swiftui-state-vs-stateobject-how-they-differ-in-usage</a> 
<a href="https://www.hackingwithswift.com/quick-start/swiftui/whats-the-difference-between-observedobject-state-and-environmentobject">https://www.hackingwithswift.com/quick-start/swiftui/whats-the-difference-between-observedobject-state-and-environmentobject</a>
</blockquote></div></div>

jwlee010523.log

이 글을 읽기 전, State와 StateObject에 대한 이해가 필요합니다. State와 StateObject가 무엇인지에 대한 내용은 아래 글을 참고해 주세요!ㅎㅎ
SwiftUI - State와 Binding
SwiftUI - StateObject
State와 StateObject를 어디에서 사용하지??
SwiftUI를 사용하다보면 언제 State와 StateObject를 언제 사용해야 하는지 고민 되는 순간이 있습니다. 결론부터 얘기하면 ViewModel은 절대로 State로 선언하면 안됩니다. 반드시 @StateObject와 @ObservedObject를 선언해야 합니다.
왜 그럴까요??
@State 는 값 타입 전용이다.
@State는 값 타입 전용 상태 프로퍼티에 쓰라고 만든 속성이기 때문입니다. ViewModel 처럼 참조 타입(class)을 관리하도록 만들어진 속성이 아닌 것이죠.
@State는 상태를 값 복사로 관리한다.
@State는 내부적으로 뷰가 상태를 직접 소유하고 재생성합니다. 즉, ViewModel 인스턴스가 뷰의 라이프사이클과 함께 자주 초기화 될 수 있습니다. 그렇게 되면 다음과 같은 문제가 발생합니다.
ViewModel의 상태가 초기화 된다.
API 호출 재실행된다.
@Published 값 변경이 UI에 반영되지 않는다.
MVVM 아키텍처를 깨드린다
또 다른 문제로는 MVVM 아키텍처를 깨뜨리는 것입니다.
MVVM에서 ViewModel은 View에 종속되지 않고, 독립적인 객체로 상태를 관리해야 합니다. 그런데 @State로 선언하면 View가 ViewModel을 직접 “가지고” 있기 때문에 View가 사라질 때마다 ViewModel도 메모리에서 자동으로 해제됩니다. 이는 위에서 언급한데로 ViewModel이 상태를 유지하지 못하게 되고, View에 종속적이게 됩니다. 
즉, View가 사라질 때 ViewModel도 함께 사라지기 때문에 상태 저장 책임이 View로 넘어가게 되어 아키텍처가 흐트러지는 것입니다.
그럼 어떻게 선언해야 할까요? 표로 정리하면 다음과 같습니다.
선언 방식
언제 쓰나
특징
@StateObject
View가 ViewModel의 소유권을 갖는 경우
View가 처음 만들어질 때 단 한번 생성되고 이후 유지됨
@ObservedObject
ViewModel을 외부에서 주입받는 경우
부모 뷰나 상위 객체에서 전달받음. ViewModel을 소유하진 않음.
@EnvironmentObject
앱 전체 또는 특정 트리에서 공유하는 경우
전역 상태 공유용
아래는 가장 일반적인 방식에 대한 예제입니다.
struct SignupView: View {
    @StateObject private var viewModel = SignupViewModel()
    var body: some View {
        // 바인딩 사용
    }
}
View가 소유하지만, 로직은 ViewModel이 담당
그럼 여기서 @StateObject도 View가 ViewModel에 대한 소유권을 갖는데, 그럼 이 경우도 ViewModel이 View에 종속 되는 것이 아닌가 하는 의문이 생길 수 있습니다.
여기서 가장 결정적인 차이점이 있는데요.
바로, @StateObject는 뷰가 처음 생성될 때 ViewModel을 단 한번만 초기화 한다는 점입니다. 반면에 @State는 값 복사 기반이라 View가 리렌더링될 때마다 ViewModel이 계속 새로 생성되기 때문인 것입니다.
사실 위에서 계속 언급해왔던 사실이죠. 
정리하면, @State와 @StateObject는 둘 다 View가 ViewModel을 소유하는 것은 맞지만 @State는 렌더링 될 때마다 계속 생성이 되고, @StateObject는 뷰 생성 시 한번만 초기화 되는 것입니다. 즉, MVVM에서는 ViewModel이 View에 소유되는 것 자체가 문제가 아니라 상태를 간접적으로 업데이트를 “지속적”으로 할 수 있느냐가 더 중요한 관점인 것입니다.
또한, @StateObject로 선언함으로써 ViewModel이 View의 생명주기에 따라 존재할 뿐, View가 ViewModel의 로직을 직접 다루거나, 상태를 바꾸지는 않습니다. 이렇게 함으로써 생성 책임은 View가 가져갈 수 있지만, “로직 책임”은 ViewModel이 하게 되어 역할을 명확히 분리할 수 있게 되는 것이죠.
MVVM을 깨는 예시
그렇다면 MVVM을 깨는 구조는 어떤 것이 있을까요? 
View에서 상태를 직접 가짐
 // 뷰에서 프로퍼티 값을 수정 및 저장
 @State var email = ""
ViewModel 없이 API 호출이나 유효성 검사 직접 처리
 // 뷰에서 직접 유효성 검사 처리
 if email.contains("@") { ... }
View가 ViewModel의 내부 상태를 바꾸는 등 로직 침범
SwiftUI에서 상태를 선언할 때 가장 중요한 것은 ‘누가 상태를 소유하고, 누가 그것을 관리하는가’입니다.
@StateObject는 View가 ViewModel을 “소유”하되, 로직에는 “침범”하지 않기 때문에 MVVM 원칙을 지키는 것입니다. 반면, @State는 값 타입에 적합한 속성으로, ViewModel처럼 참조 타입인 객체에는 절대 사용해서는 안 됩니다.
따라서 ViewModel은 항상 @StateObject 또는 @ObservedObject로 관리하고, @State는 값 타입의 간단한 View내부 상태에만 사용하는 것이 좋습니다.
출처
https://developer.apple.com/documentation/swiftui/state
https://developer.apple.com/documentation/swiftui/stateobject
https://www.dhiwise.com/post/swiftui-state-vs-stateobject-how-they-differ-in-usage
https://www.hackingwithswift.com/quick-start/swiftui/whats-the-difference-between-observedobject-state-and-environmentobject

SwiftUI @State와 @StateObject를 언제 어디에 선언해야 하는가

댓글