[Week8] seungjun - Compose Rumtime

docs/seungjun/week8/Q-1-11.md

@@ -0,0 +1,15 @@
+# Q) 11. 상태(State)란 무엇이며 이를 관리하는 데 사용되는 API는 무엇인가요?
+
+Jectpack Compose 에서 상태를 관리하기 위해 여러 API 를 제공한다.
+
+### Compose 에서 상태 관리
+
+1. `remember`: 초기 컴포지션 발생시 메모리에 객체를 저장하고 recomposition 이 발생하면 기존 메모리에 저장된 값을 꺼내옵니다.
+2. `rememberSavable`: recomposition 뿐 아니라, 화면 회전과 같은 구성 변경 시에도 화면 상태를 유지합니다. Bundle 에 저장할 수 있는 유형(`parcelable`) 또는 그 외 유형에 대해서는 커스텀 saver 객체와 함께 작동합니다.
+3. `mutableStateOf`: 가변적인 상태를 의미, 상태 값이 변경될 때 recomposition 을 트리거하는 관찰 가능한 상태 객체를 생성
+
+### 실전 질문
+
+Q) 상태는 recomposition과 어떤 관련이 있으며, recomposition이 발생하면 내부적으로 어떤 일이 발생하나요?
+
+`mutableStateOf` 로 설정된 값과 같은 상태는 변경시에 `recomposition` 을 트리거하여 데이터의 변경 사항(상태)을 UI에 반영합니다. 다만 단순 `mutableStateOf` 를 사용시 리컴포지션 되면서 해당 값을 잃기 때문에 해당 값을 잃지 않기 위해 `remember` 로 메모리에 값을 저장 하고, 리컴포지션시에 해당 메모리에 값을 다시 불러오게 합니다.

docs/seungjun/week8/Q-1-12.md

@@ -0,0 +1,64 @@
+# Q) 12. 상태 호이스팅(state hoisting)으로 어떤 이점을
+얻을 수 있나요?
+
+상태 호이스팅(State Hositing) 은 상태를 상위 수준의 컴포저블 함수로 끌어 올리는 것으로 일종의 디자인 패턴을 의미합니다.
+
+단방향 데이터 흐름 원칙을 따라 UI 를 더 쉽게 관리하고 확장 가능하게 만듭니다.
+
+**State** : 부모 컴포저블에서 관리, 상태 호이스팅을 적용하려는 컴포저블은 상태를 가져서는 안된다.
+
+**Events** or **Triggers** : onClick, onValueChange 와 같은 이벤트는 자식에서 값을 바꾸고 이를 부모로 전달 받는 형태로 업데이트, 자식 컴포저블에서 콜백 방식으로 해당 상태를 업데이트합니다.
+
+이렇게 `Stateless` 한 상태를 유지하는 것이 중요합니다.
+
+### 왜 Stateless 하게 유지해야하는가?
+
+state hoisting 의 장점은 다음과 같습니다.
+
+- Single source of truth: 단일 출처만을 보장하게할 수 있습니다. 상태가 얽히는 것을 예방합니다.
+- Encapsulated: 캡슐화를 통해 상태 수정을 stateful 컴포저블에서만 조작합니다.
+    - 상태가 없는 컴포저블은 테스트가 더 간단해집니다.
+- Shareable: 여러 컴포저블에 상태를 공유 할 수 있습니다.
+
+### 실전 질문
+
+Q) 상태 호이스팅이 왜 컴포저블 함수의 재사용성과 테스트 용이성을 향상시키나요? 예시를 들어서 설명해 주세요.
+
+- 상태 호이스팅은 컴포저블이 상태를 직접 관리하지 않고 값과 이벤트만 전달받게 하여 UI 표현에만 집중하게 만든다.
+- 그 결과 컴포저블이 특정 로직이나 초기값에 종속되지 않아 다양한 화면과 상황에서 재사용이 쉬워진다.
+- 또한 상태를 외부에서 주입할 수 있어 테스트 시 원하는 상태를 직접 설정할 수 있어 테스트가 단순하고 예측 가능해진다.
+
+Q) 어떤 시나리오에서 상태 호이스팅을 사용하지 않고, 컴포저블 내부에 상태를 갖도록 하실 건가요? 해당 시나리오에서는 컴포저블에 상태를 갖도록 하는 것이 상태 호이스팅을 적용하는 것에 비해 어떤 장점을 갖나요?
+
+**1️⃣ 해당 상태가 UI 내부에서만 의미를 갖는 경우**
+
+예를 들어,
+
+- 버튼의 pressed 상태
+- 텍스트 필드의 포커스 여부
+- 임시 애니메이션 진행 상태
+- 토글의 열림/닫힘 여부
+
+처럼 **외부에서 알 필요가 없고, UI 표현에만 국한된 상태**라면
+
+굳이 상위로 상태를 끌어올리지 않고 컴포저블 내부에서 관리합니다.
+
+**2️⃣ 재사용되거나 공유될 필요가 없는 상태인 경우**
+
+상태가 다른 컴포저블과 공유되지 않고
+
+외부 로직이나 비즈니스 규칙에 영향을 주지 않으며 특정 UI 구현에만 종속적인 경우
+
+이런 상태까지 호이스팅하면 오히려 **불필요한 파라미터 증가와 구조 복잡도**만 높아집니다.
+
+**3️⃣ 이 경우 컴포저블 내부 상태의 장점**
+
+이러한 시나리오에서는 내부 상태를 사용하는 것이 다음과 같은 장점을 가집니다.
+
+- **코드 단순성:** 상위 컴포저블에 불필요한 상태와 이벤트를 전달하지 않아도 됨
+- **캡슐화:** UI 구현 세부사항을 컴포저블 내부에 숨길 수 있음
+- **가독성:** “이 상태는 이 UI에만 쓰인다”는 의도가 코드에서 명확해짐
+
+즉, 모든 상태를 호이스팅하는 것보다
+
+**UI 전용 상태는 컴포저블 내부에 두는 편이 오히려 유지보수에 유리**합니다.

docs/seungjun/week8/Q-1-13.md

@@ -0,0 +1,135 @@
+# Q) 13. remember와 rememberSaveable의 차이점은 무엇인가요?
+
+### remember
+
+목적: 메모리에 값을 저장하고 recomposition 시 메모리에 저장된 값을 꺼내 상태를 유지
+
+사용: 구성 변경 후에 데이터가 날라가도 되는 상태에 사용, 애니메이션이나 임시적 UI 상태
+
+내부 구조
+
+```kotlin
+@Composable
+public inline fun <T> remember(crossinline calculation: @DisallowComposableCalls () -> T): T =
+    currentComposer.cache(false, calculation)
+
+@ComposeCompilerApi
+public inline fun <T> Composer.cache(invalid: Boolean, block: @DisallowComposableCalls () -> T): T {
+    @Suppress("UNCHECKED_CAST")
+    return rememberedValue().let {
+        if (invalid || it === Composer.Empty) {
+            val value = block()
+            updateRememberedValue(value)
+            value
+        } else it
+    } as T
+}
+```
+
+Compose 컴파일러 플러그인 API(`updateRememberedValue`) 를 호출하여 컴포지션 데이터 값을 캐시합니다.
+
+값이 유효하지 않거나, 초기화 되지 않았는지 확인하고 초기화되지 않았으면 블록 람다 함수를 사용해 값을 계산하고 컴포지션 데이터에 저장한 다음 반환합니다.
+
+### rememberSaveable
+
+목적: 구성 변경시에도 상태를 유지하여 더 넓은 범위에서 상태를 저장하고 복원, `SDK 의 Bundle` 에 저장할 수 있는 값에 한해 자동으로 저장하고 복원
+
+사용: 유저 인풋 입력이나 네비게이션 상태와 같이 구성 변경 후에도 유지되어야 하는 상태에 사용
+
+- 복잡한 객체에 대해 커스텀 Saver 를 지원합니다.
+
+내부구조
+
+```kotlin
+@Composable
+public fun <T : Any> rememberSaveable(
+    vararg inputs: Any?, // 상태 재계산 트리거 하기 위한 입력 키
+    saver: Saver<T, out Any> = autoSaver(), // 상태 저장 및 복원 로직
+    key: String? = null, // 상태 저장을 위한 고유 키
+    init: () -> T, // 초기값 계산 람다
+): T {
+    val compositeKey = currentCompositeKeyHashCode
+    // key is the one provided by the user or the one generated by the compose runtime
+    val finalKey =
+        if (!key.isNullOrEmpty()) {
+            key
+        } else {
+            compositeKey.toString(MaxSupportedRadix)
+        }
+    @Suppress("UNCHECKED_CAST") (saver as Saver<T, Any>)
+
+    val registry = LocalSaveableStateRegistry.current
+
+    val holder = remember {
+        // value is restored using the registry or created via [init] lambda
+        val restored = registry?.consumeRestored(finalKey)?.let { saver.restore(it) }
+        val finalValue = restored ?: init()
+        SaveableHolder(saver, registry, finalKey, finalValue, inputs)
+    }
+
+    val value = holder.getValueIfInputsDidntChange(inputs) ?: init()
+    // 리컴포지션 시 상태 업데트 및 레지스트리 등록
+    SideEffect { holder.update(saver, registry, finalKey, value, inputs) }
+
+    return value
+}
+```
+
+1. 키 생성: key 매개변수를 통해 사용자가 커스텀 키를 제공할 수 있다. 커스텀 키가 없으면 현재 컴포지션 해시를 사용해 복합 키가 자동으로 생성된다.
+
+    ```kotlin
+    val compositeKey = currentCompositeKeyHashCode
+        // key is the one provided by the user or the one generated by the compose runtime
+        val finalKey =
+            if (!key.isNullOrEmpty()) {
+                key
+            } else {
+                compositeKey.toString(MaxSupportedRadix)
+            }
+    ```
+
+2. 상태 복원: `LocalSaveableStateRegistry` 는 주어진 키에 대해 이전에 저장된 값이 있는지 확인 후, 값이 존재하면 Saver 를 통해 복원된다.
+
+    ```kotlin
+    val registry = LocalSaveableStateRegistry.current
+    val restored = registry?.consumeRestored(finalKey)?.let { saver.restore(it) }
+    ```
+
+3. 기본값 초기화: 복원된 값이 없으면 init 람다를 통해 기본값이 초기화 된다.
+
+    ```kotlin
+    val finalValue = restored ?: init()
+    ```
+
+4. Saveable Holder: 상태, saver, 레지스트리 및 입력을 관리하기 위해 SaveableHolder 가 생성된다.
+
+    ```kotlin
+    SaveableHolder(saver, registry, finalKey, finalValue, inputs)
+    ```
+
+5. 입력 변경 처리: `rememberSaveable` 에 대한 입력이 변경되면 상태가 무효화 되고 값이 다시 초기화 된다.
+
+    ```kotlin
+    val value = holder.getValueIfInputsDidntChange(inputs) ?: init()
+    ```
+
+6. 사이드 이팩트: SideEffect 를 통해 리컴포지션 시 업데이트된 상태가 레지스트리에 저장된다.
+
+    ```kotlin
+    SideEffect { holder.update(saver, registry, finalKey, value, inputs) }
+    ```
+
+
+기본적으로 `LocalSaveableStateRegistry` 를 통해 구성 변경시에도 상태를 보존하게 하는 구조이다.
+
+### 실전 질문
+
+Q) remember이 아닌 rememberSaveable를 사용해야하는 시나리오는 무엇이며, 어떤 트레이드오프를 고려해야 하나요?
+
+기본적으로 rememberSaveable 은 초기화 및 직렬화 역직렬화 로직이 추가적으로 들어가기에 해당 리소스를 remember 보다는 더 많이 가져간다고 볼수 있습니다. 따라서 사용자 입력과 같이 데이터를 구성 변경시 잃어버리지 않게 하기 위해서 사용하고, 그외 중요하지 않는 데이터(잃어도 되는 데이터는) remember 로 가볍게 관리하는것이 좋습니다.
+
+Q) 기본적으로 지원되지 않는 커스텀 비원시(non‑primitive) 값 로 저장하려면 어떻게 해야 하나요?
+
+`rememberSaveable` 은 기본적으로 **Bundle에 저장 가능한 타입만** 지원하기 때문에,
+
+커스텀 비원시 타입은 **직접 저장·복원 방법을 정의한 `Saver`를 구현해 사용** 합니다.

docs/seungjun/week8/Q-1-14.md

@@ -0,0 +1,65 @@
+# Q) 14. 컴포저블 함수 내에서 안전하게 코루틴 스코프(coroutine scope)를 생성하는 방법은 무엇인가요?
+
+기본적으로 Compose 에서 코루틴 스코프를 생성하기 위해서는 `rememberCoroutineScope` 를 사용합니다.
+
+### rememberCoroutineScope 사용 이유
+
+`rememberCoroutineScope` 는 컴포저블이 컴포지션을 벗어날 때 활성 중인 코루틴 스코프를 자동으로 취소합니다. 내부적으로 컴포저블 함수의 내부 생명주기를 인지하여 동작하기에 개발자는 수동으로 생명주기를 관리할 필요가 없습니다.
+
+↔ GlobalScope 앱 전역에 사용되는 Scope로 코루틴 스코프를 수동으로 관리해야합니다.
+
+컴포저블이 사라져도 유지되어야하는 경우, viewmodel 의 ViewModelScope 를 사용하거나, lifecycleScope 를 사용해 생명주기 관리를 보장하면서 예기치 않은 작업 취소를 방지할 수 있습니다.
+
+### rememberCoroutineScope 내부 구조
+
+```kotlin
+@Composable
+public inline fun rememberCoroutineScope(
+    crossinline getContext: @DisallowComposableCalls () -> CoroutineContext = {
+        EmptyCoroutineContext
+    }
+): CoroutineScope {
+    val composer = currentComposer
+    return remember { createCompositionCoroutineScope(getContext(), composer) }
+}
+
+@PublishedApi
+@OptIn(InternalComposeApi::class)
+internal fun createCompositionCoroutineScope(
+    coroutineContext: CoroutineContext,
+    composer: Composer,
+): CoroutineScope =
+    if (coroutineContext[Job] != null) {
+        CoroutineScope(
+            Job().apply {
+                completeExceptionally(
+                    IllegalArgumentException(
+                        "CoroutineContext supplied to " +
+                            "rememberCoroutineScope may not include a parent job"
+                    )
+                )
+            }
+        )
+    } else {
+        val applyContext = composer.applyCoroutineContext
+        RememberedCoroutineScope(applyContext, coroutineContext)
+    }
+```
+
+`createCompositionCoroutineScope` 를 통해 주어진 코루틴 컨텍스트에 대해 새 코루틴 스코프를 생성하는 역할을 합니다.
+
+**상위 Job 제한**: 제공된 `CoroutineContext` 에서 Job 을 포함하고 있는 경우 예외가 발생합니다. `rememberCoroutineScope` 가 기존의 상위 Job 에 종속되는 것이 아닌 독립적 스코프를 생성하도록 보장합니다.
+
+**Job 관리**:스코프를 관리하기 위해 Job 이 코루틴 컨텍스트에 추가됩니다.
+
+**Composer 통합**: `composer.applyCoroutineContext` 를 새로 생성된 Job 과 결합해 코루틴 스코프를 설정합니다.
+
+### 실전 질문
+
+Q) 컴포저블 내에서 직접 코루틴 스코프를 생성하고 시작하면 어떤 위험성이 발생할 수 있나요? `rememberCoroutineScope`를 사용해야 하는 이유가 무엇인가요?
+
+`rememberCoroutineScope()`는 **Composable의 Composition 생명주기에 묶인 스코프**를 제공합니다.
+
+같은 Composition 동안은 **스코프가 재사용**되어 리컴포지션마다 새로 만들어지지 않아요. Composable이 Composition에서 제거되면 **자동으로 cancel**되어 누수/백그라운드 작업을 줄입니다.
+
+즉, UI 이벤트(버튼 클릭 등)로 “즉시 실행하는 작업”을 안전하게 launch할 수 있게 해줍니다.