9148c358d0
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
3.6 KiB
3.6 KiB
id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases
| id | title | category | status | source_trust_level | verification_status | created_at | updated_at | tags | tech_stack | applied_in | aliases | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| android-compose-state-hoisting | Jetpack Compose — State Hoisting | Coding | draft | B | conceptual | 2026-05-09 | 2026-05-09 |
|
|
|
Compose State Hoisting
Composable 은 가능한 stateless. state 는 호출자가 보유, (value, onValueChange) 한 쌍 으로 주입. 테스트 / 재사용 / preview 모두 쉬워짐. React 의 controlled component 와 같은 철학.
📖 핵심 개념
- Stateful: 자기 안에
remember { mutableStateOf(...) }보유. - Stateless: state 를 외부에서 받음. 같은 입력 = 같은 UI.
- Hoist: state 를 가장 가까운 공통 부모로 끌어올림.
💻 코드 패턴
Stateless + 호출자 hoist
@Composable
fun NameField(
name: String,
onNameChange: (String) -> Unit,
modifier: Modifier = Modifier,
) {
OutlinedTextField(
value = name,
onValueChange = onNameChange,
label = { Text("이름") },
modifier = modifier,
)
}
// 호출자
@Composable
fun ProfileScreen(viewModel: ProfileViewModel) {
val name by viewModel.name.collectAsStateWithLifecycle()
NameField(name = name, onNameChange = viewModel::onNameChange)
}
두 컴포저블이 같은 state 공유 → 부모로 hoist
@Composable
fun PriceWidget() {
var price by rememberSaveable { mutableStateOf(0) }
Row {
PriceSlider(value = price, onValueChange = { price = it })
PriceLabel(value = price)
}
}
rememberSaveable — config change 에 보존
var query by rememberSaveable { mutableStateOf("") }
// 화면 회전 시에도 유지 (Bundle 자동 복원)
복잡 state — Holder 패턴
@Stable
class FormState(initial: String = "") {
var name by mutableStateOf(initial)
var isValid by derivedStateOf { name.length >= 2 }
}
@Composable
fun rememberFormState(initial: String = "") = remember { FormState(initial) }
@Composable
fun Form() {
val state = rememberFormState()
NameField(name = state.name, onNameChange = { state.name = it })
if (state.isValid) Button(onClick = ...) { Text("제출") }
}
🤔 의사결정 기준
| 상황 | 패턴 |
|---|---|
| 한 composable 내부 UI state (toggle 펼침 등) | remember { mutableStateOf } |
| 두 형제가 같은 state | 부모로 hoist |
| screen 단위 비즈니스 state | ViewModel + StateFlow |
| 화면 회전 보존 | rememberSaveable |
| 여러 필드 + 검증 | State Holder 클래스 |
❌ 안티패턴
- 모든 state 를 ViewModel 까지 끌어올림: 작은 toggle 도 viewmodel 행. 가까운 공통 부모로.
- stateful + props 동시 보유 (
var x by remember(...)+prop x): 어느 게 진실?. 한쪽으로. MutableState를 직접 외부 노출: 캡슐화 깨짐. State 만 노출.- rememberSaveable 안에 너무 큰 객체: Bundle 한계 / TransactionTooLarge crash.
- Composable 안에서
LaunchedEffect없이 launch: lifecycle 관리 안 됨. - derivedStateOf 안 쓰고 매번 계산: 불필요 recomposition.
🤖 LLM 활용 힌트
- "이 state 가 누구의 것인가? 가장 가까운 공통 부모는?" 매 composable 작성 시 점검.
- ViewModel 은 비즈니스 state, composable 은 UI-local state 만.