프로바이더 보다 블럭을 쓰는 이유

1.비즈니스 로직과 UI를 엄격하게 분리한다 . 

프로바이더 쓸때는 닉네임 변화 할때 닉네임 글자 변경하면서  변화하는 로직도 던져주니

가끔 순서때문에 이름에 널값뜨거나 그랬는데, (타이밍 이슈)
블럭 쓰면 ui 변화 따로 시키고 로직도 따로 변화 시켜주니 널 값 뜰 확률이 줄어든다 (순차적으로 처리)

그리고 어디가 문제인지 정확히 짚어서 수정할 수 있다.

 

2. 단방향 통신

프로바이더 쓸때는 닉네임 변화 시킬때 ChangeNotifier에서 직접 상태 변경 메서드를 호출해서

서로 호출하다 무한 루프가 걸릴 때가 있었다.
(ChangeNotifier를 통해 어디서든 상태를 변경할 수 있어 순환 의존성이 발생할 리스크가 있다.)

하지만 블럭 쓸때는 UI에서 이벤트 발생 → BLoC이 이벤트 수신 → BLoC이 상태 변경 → UI에 새 상태 전달 → UI 업데이트
이런식으로 한 방향으로만 가기 때문에

서로 오고가다 충돌하지 않는다.

 

ㅡㅡㅡㅡㅡㅡㅡ

 

BLoC을 사용하는 가장 중요한 이유 두 가지는:

1. 명확한 관심사 분리: BLoC은 비즈니스 로직과 UI를 엄격하게 분리하여 코드 구조가 더 깔끔하고 유지보수가 용이합니다.
2. 예측 가능한 단방향 데이터 흐름: 이벤트 기반 아키텍처로 상태 변화가 예측 가능하며 디버깅이 쉽습니다.

단방향 데이터 흐름이란?

단방향 데이터 흐름은 데이터가 한 방향으로만 흐르는 아키텍처 패턴입니다:

1. BLoC에서의 데이터 흐름:
   • UI에서 이벤트 발생 → BLoC이 이벤트 수신 → BLoC이 상태 변경 → UI에 새 상태 전달 → UI 업데이트
   • 데이터는 항상 이 순서로만 흐르며, 역방향으로 흐르지 않음
2. Provider와의 차이:
   • Provider가 반드시 양방향이라기보다는, BLoC이 더 엄격한 단방향 흐름을 강제함
   • Provider는 ChangeNotifier에서 직접 상태 변경 메서드를 호출할 수 있어 흐름이 덜 명시적
3. 장점:
   • 상태 변화의 출처를 쉽게 추적 가능
   • 디버깅이 용이함
   • 코드 예측 가능성 향상