[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
+175
-100
@@ -1,128 +1,203 @@
|
||||
---
|
||||
id: wiki-2026-0508-bloc
|
||||
title: BLoC
|
||||
category: Architecture
|
||||
status: needs_review
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [BLoC, Business Logic Component, flutter_bloc]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [auto-wikified, technical-documentation, architecture]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [flutter, state-management, dart, reactive]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: dart
|
||||
framework: flutter,flutter_bloc
|
||||
---
|
||||
|
||||
# BLoC
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
BLoC(Business Logic Component)는 Flutter 생태계에서 프로젝트의 규모에 따라 활용되는 스트림(Stream) 기반의 이벤트 중심 상태 관리 패턴입니다 [1]. 이 패턴은 엄격한 관심사 분리를 요구하여 비즈니스 로직을 분리하는 데 사용됩니다 [1]. 높은 테스트 용이성과 상태 변화에 대한 예측 가능성을 제공하기 때문에, 특히 대규모 엔터프라이즈 프로젝트에서 널리 선호되는 아키텍처 패턴입니다 [1].
|
||||
## 매 한 줄
|
||||
> **"매 UI ↔ business logic 의 strict separation — Event in · State out · Stream 으로 의 mediate"**. 2018 Felix Angelov · Paolo Soares Google I/O 의 introduce, 2026 의 flutter_bloc 9.x · Cubit · Hydrated 의 Flutter ecosystem 의 dominant state-management.
|
||||
|
||||
## 📖 Core 소스에 기반한 Content
|
||||
* **스트림 및 이벤트 중심 아키텍처**: BLoC는 데이터의 흐름을 스트림(Stream)을 기반으로 처리하며, 이벤트 중심(Event-driven) 방식으로 상태 관리를 수행합니다 [1].
|
||||
* **엄격한 관심사 분리**: 애플리케이션 내에서 UI(프레젠테이션) 레이어와 비즈니스 로직 레이어를 엄격하게 분리하도록 강제합니다 [1].
|
||||
* **대규모 엔터프라이즈 환경 최적화**: BLoC 패턴이 강제하는 엄격한 구조적 특징은 코드의 예측 가능성을 높이고 테스트를 매우 용이하게 만듭니다. 이러한 장점 덕분에 복잡도가 높은 대규모 엔터프라이즈 모바일 프로젝트를 설계할 때 가장 적합한 상태 관리 방식으로 평가받고 있습니다 [1].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
BLoC 패턴은 애플리케이션의 테스트 용이성과 예측 가능성을 극대화하지만, 그 반대급부로 설계 시 '엄격한 관심사 분리'를 반드시 충족해야 하는 제약과 복잡성이 따릅니다 [1]. 상대적으로 배우기 쉽고 유연하여 중소규모 프로젝트에서 높은 생산성을 내는 Provider나 Riverpod 상태 관리 패턴에 비해, 초기 구조를 잡고 유지하는 데 더 높은 학습 곡선과 코딩 비용(보일러플레이트 등)이 요구될 수 있음을 시사합니다 [1]. 그 외 BLoC 패턴의 기술적 부작용이나 최적화 한계에 대해서는 소스에 관련 정보가 부족합니다.
|
||||
### 매 contract
|
||||
- **Event**: input (button tap · API tick).
|
||||
- **State**: output (immutable snapshot).
|
||||
- **Bloc**: `mapEventToState` (legacy) → `on<Event>` handler (modern 8.x+).
|
||||
- **Cubit**: simpler — 매 event 의 X, method 의 emit 의 directly.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
### Related Concepts
|
||||
### 매 component
|
||||
- `BlocProvider` — DI · scope.
|
||||
- `BlocBuilder` — rebuild 의 state change 의 reactive.
|
||||
- `BlocListener` — side-effect (snackbar · navigation).
|
||||
- `BlocConsumer` — builder + listener.
|
||||
- `RepositoryProvider` — data layer DI.
|
||||
|
||||
#### [상태 관리 아키텍처 (State Management Patterns)]
|
||||
- [[Provider & Riverpod]]
|
||||
- 연결 이유: Flutter 생태계에서 BLoC과 경쟁하는 또 다른 주요 상태 관리 패턴들입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: BLoC이 대규모 엔터프라이즈용으로 적합한 반면, Provider와 Riverpod는 중소규모 프로젝트에서 생산성과 유연성을 어떻게 제공하는지 대조적으로 비교하며 적절한 기술 스택을 선정하는 기준을 이해할 수 있습니다 [1].
|
||||
### 매 응용
|
||||
1. 매 Flutter 의 production app (BMW · Nubank · Alibaba).
|
||||
2. Form validation (매 reactive validation per field).
|
||||
3. Authentication flow.
|
||||
4. Hydrated state (매 disk-persisted, app restart 의 survive).
|
||||
|
||||
#### [기반 기술 및 프레임워크 (Foundational Tech & Framework)]
|
||||
- [[스트림(Stream)]]
|
||||
- 연결 이유: BLoC 패턴이 상태와 이벤트를 처리하기 위해 근간으로 삼고 있는 데이터 비동기 흐름 처리 메커니즘입니다 [1].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: BLoC 내부에서 UI 이벤트가 비즈니스 로직으로 전달되고, 변경된 상태가 다시 UI로 방출되는 구조적 원리를 이해할 수 있습니다.
|
||||
- [[Flutter]]
|
||||
- 연결 이유: BLoC이 상태 관리 솔루션으로 활발하게 사용되는 구글의 크로스 플랫폼 모바일 개발 프레임워크입니다 [1, 2].
|
||||
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: Flutter가 지닌 선언적 UI 구조와 BLoC 패턴이 어떻게 결합하여 모바일 생태계의 성능과 개발 생산성을 끌어올리는지 이해할 수 있습니다 [1, 2].
|
||||
## 💻 패턴
|
||||
|
||||
### Deeper Research Questions
|
||||
- BLoC 패턴이 기반으로 하는 스트림(Stream) 처리 방식은 Redux Toolkit이나 Zustand와 같은 타 프레임워크의 상태 관리 메커니즘과 비교할 때 렌더링 성능 최적화 측면에서 어떤 구조적 이점과 단점을 가지는가?
|
||||
- 대규모 엔터프라이즈 애플리케이션에서 BLoC을 활용할 때, 횡단 관심사(예: 에러 핸들링, 로깅)는 BLoC 구조 내에서 어떻게 주입되고 관리되어야 하는가?
|
||||
- 엄격한 관심사 분리로 인해 필연적으로 발생하는 BLoC의 보일러플레이트 코드를 최소화하기 위해 실무에서는 어떤 코드 제너레이션(Code Generation) 도구나 디자인 패턴을 병행하는가?
|
||||
- 최근 부상한 반응형 패턴인 Riverpod와 BLoC 간의 구체적인 아키텍처적 차이는 무엇이며, BLoC에서 Riverpod로 마이그레이션할 때 얻을 수 있는 이득과 손실은 무엇인가?
|
||||
- 이벤트 중심(Event-driven) 상태 관리를 수행하는 BLoC 모델에서 캐싱(Caching) 및 오프라인 데이터 동기화 전략은 어떻게 결합하여 사용되는가?
|
||||
### Bloc (event-driven)
|
||||
```dart
|
||||
sealed class CounterEvent {}
|
||||
class Increment extends CounterEvent {}
|
||||
class Decrement extends CounterEvent {}
|
||||
|
||||
### Practical Application Contexts
|
||||
class CounterBloc extends Bloc<CounterEvent, int> {
|
||||
CounterBloc() : super(0) {
|
||||
on<Increment>((event, emit) => emit(state + 1));
|
||||
on<Decrement>((event, emit) => emit(state - 1));
|
||||
}
|
||||
}
|
||||
|
||||
- **Implementation:** Flutter 앱 개발 시, UI에서 발생한 사용자 이벤트를 스트림 기반으로 수신하고 순수한 비즈니스 로직만을 처리한 후, 새로운 상태를 배출하도록 컴포넌트를 구현하는 데 적용됩니다 [1]. (구체적인 구현 코드나 라이브러리 사용법에 대해서는 소스에 관련 정보가 부족합니다.)
|
||||
- **System Design:** 유지보수와 확장이 필수적인 대규모 엔터프라이즈 모바일 플랫폼의 아키텍처를 설계할 때, UI와 비즈니스 로직의 결합도를 낮추기 위한 표준 패턴으로 도입됩니다 [1].
|
||||
- **Operation / Maintenance:** 상태 변화의 원인이 이벤트로 명확히 분리되고 예측 가능성이 높아지므로, 향후 애플리케이션의 버그 추적이나 기능 변경 시 안정적인 유지보수가 가능해집니다 [1].
|
||||
- **Learning Path:** Flutter를 학습하는 개발자가 기초적인 상태 관리를 넘어 대규모 아키텍처 지식을 강화하고자 할 때 필수적으로 탐구해야 하는 패턴입니다 [2].
|
||||
- **My Project Relevance:** 복잡도 높은 비즈니스 로직과 철저한 단위 테스트가 요구되는 대형 모바일 프로젝트를 기획하거나 설계 중일 때 즉각적으로 도입을 고려해야 하는 아키텍처 설계 기준이 됩니다 [1].
|
||||
|
||||
### Adjacent Topics
|
||||
|
||||
- [[React Native 상태 관리 (Redux Toolkit, Zustand, React Query)]]
|
||||
- 확장 방향: Flutter 생태계의 BLoC 및 Riverpod 패턴과 대조되는 React Native 진영의 상태 관리 패턴(Redux Toolkit, Zustand, TanStack Query 등)을 함께 조사하여, 크로스 플랫폼 프레임워크 전반의 최신 상태 관리 트렌드와 철학적 차이를 폭넓게 이해할 수 있습니다 [1].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
|
||||
**추출된 패턴:**
|
||||
> *(TODO)*
|
||||
|
||||
**세부 내용:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
// usage
|
||||
BlocProvider(
|
||||
create: (_) => CounterBloc(),
|
||||
child: BlocBuilder<CounterBloc, int>(
|
||||
builder: (ctx, count) => Text('$count'),
|
||||
),
|
||||
)
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### Cubit (simpler · method-based)
|
||||
```dart
|
||||
class CounterCubit extends Cubit<int> {
|
||||
CounterCubit() : super(0);
|
||||
void increment() => emit(state + 1);
|
||||
void decrement() => emit(state - 1);
|
||||
}
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
// trigger
|
||||
context.read<CounterCubit>().increment();
|
||||
```
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
### Async event handler with state machine
|
||||
```dart
|
||||
sealed class LoginState {}
|
||||
class LoginInitial extends LoginState {}
|
||||
class LoginLoading extends LoginState {}
|
||||
class LoginSuccess extends LoginState { final User user; LoginSuccess(this.user); }
|
||||
class LoginFailure extends LoginState { final String msg; LoginFailure(this.msg); }
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
class LoginBloc extends Bloc<LoginEvent, LoginState> {
|
||||
final AuthRepository auth;
|
||||
LoginBloc(this.auth) : super(LoginInitial()) {
|
||||
on<SubmitLogin>(_onSubmit);
|
||||
}
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
Future<void> _onSubmit(SubmitLogin e, Emitter<LoginState> emit) async {
|
||||
emit(LoginLoading());
|
||||
try {
|
||||
final user = await auth.login(e.email, e.password);
|
||||
emit(LoginSuccess(user));
|
||||
} catch (err) {
|
||||
emit(LoginFailure(err.toString()));
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### BlocListener (side-effect)
|
||||
```dart
|
||||
BlocListener<LoginBloc, LoginState>(
|
||||
listener: (ctx, state) {
|
||||
if (state is LoginSuccess) Navigator.pushNamed(ctx, '/home');
|
||||
if (state is LoginFailure) ScaffoldMessenger.of(ctx).showSnackBar(
|
||||
SnackBar(content: Text(state.msg)),
|
||||
);
|
||||
},
|
||||
child: LoginForm(),
|
||||
)
|
||||
```
|
||||
|
||||
### Hydrated Bloc (auto-persist)
|
||||
```dart
|
||||
class SettingsCubit extends HydratedCubit<Settings> {
|
||||
SettingsCubit() : super(const Settings(theme: 'light'));
|
||||
|
||||
void setTheme(String t) => emit(state.copyWith(theme: t));
|
||||
|
||||
@override
|
||||
Settings fromJson(Map<String, dynamic> json) => Settings.fromJson(json);
|
||||
|
||||
@override
|
||||
Map<String, dynamic> toJson(Settings state) => state.toJson();
|
||||
}
|
||||
```
|
||||
|
||||
### Stream-debounced search Bloc
|
||||
```dart
|
||||
class SearchBloc extends Bloc<SearchQuery, SearchState> {
|
||||
SearchBloc(this.api) : super(SearchInitial()) {
|
||||
on<SearchQuery>(
|
||||
_onSearch,
|
||||
transformer: (events, mapper) => events
|
||||
.debounceTime(const Duration(milliseconds: 300))
|
||||
.switchMap(mapper),
|
||||
);
|
||||
}
|
||||
|
||||
Future<void> _onSearch(SearchQuery e, Emitter<SearchState> emit) async {
|
||||
emit(SearchLoading());
|
||||
final results = await api.search(e.term);
|
||||
emit(SearchLoaded(results));
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Test (bloc_test)
|
||||
```dart
|
||||
blocTest<CounterBloc, int>(
|
||||
'emits [1] when Increment is added',
|
||||
build: () => CounterBloc(),
|
||||
act: (b) => b.add(Increment()),
|
||||
expect: () => [1],
|
||||
);
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| Simple state · single screen | Cubit |
|
||||
| Complex event flow · undo/redo | Bloc |
|
||||
| Persisted state | HydratedBloc/Cubit |
|
||||
| Server-driven · realtime | Bloc + StreamSubscription |
|
||||
| Multi-screen shared | BlocProvider 의 root |
|
||||
| 매 small project | Provider · Riverpod |
|
||||
|
||||
**기본값**: Cubit 의 first, Bloc 의 event 의 explicit 의 require 의 case.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[State Management]] · [[Reactive Programming]]
|
||||
- 변형: [[Cubit]] · [[Hydrated Bloc]] · [[ReplayBloc]]
|
||||
- 응용: [[Flutter App Architecture]] · [[Clean Architecture]]
|
||||
- Adjacent: [[Provider]] · [[Riverpod]] · [[GetX]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: Bloc · Cubit · Event · State 의 boilerplate 의 generate, blocTest 의 draft.
|
||||
**언제 X**: 매 actual event sequencing · concurrency strategy (debounce/restartable/sequential) — 매 domain 의 understand 의 require.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **State 의 mutable**: 매 immutable + copyWith 의 mandatory.
|
||||
- **BlocBuilder 의 entire screen 의 wrap**: granular rebuild 의 lose — multiple builder 의 split.
|
||||
- **Bloc 의 navigation 의 directly do**: side-effect 의 BlocListener 의 isolate.
|
||||
- **Singleton bloc 의 manual instantiate**: BlocProvider 의 use — lifecycle 의 leak prevent.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (bloclibrary.dev, flutter_bloc 9.x docs, Felix Angelov GitHub).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Bloc + Cubit + Hydrated + bloc_test patterns |
|
||||
|
||||
Reference in New Issue
Block a user