[TIL] 21.04.08

스트림

또 딴길로 샜는데, 보다보니 Stream이 궁금해져서(역시 마찬가지로 BloC 패턴에서 사용되는 기술이라는데) 함께 공부해보았다.

스트림은 비단 플러터만의 개념은 아니다. 이는 비동기 작업을 할 때 자주 사용되는 개념이다.
예전에 회사 다녔을 때 스트림에 대한 사수분의 설명을 빌리자면 데이터가 흐르는 강이라고 할 수 있다.

앱 내에서 다루는 데이터가 많을 때, 웹에서 데이터를 가져오는 것이 시간이 오래 걸린다면 이것을 기다렸다가 다음 단계로 넘어가고.. 비효율적이고 답답할 것이다.
이런 것을 해결하기 위한 방법이 비동기 처리이다. 데이터는 데이터대로 가져오고 있도록 하고, 나머지는 일단 각자의 일을 하는 것이다. 그러다가 데이터가 다 가져와졌다면(혹은 최소 사용할 수 있는 만큼 가져와졌다면) 그 데이터를 받아와 처리하는 것이 비동기 방식이다.

이 비동기 방식을 구현하기 위한 방법 중 하나가 스트림이다.

스트림은 비동기 방식의 구현 뿐만 아니라, 엡 전체를 강처럼 흐르고 있는 데이터들을 쭉 관찰하면서(구독이라는 표현도 사용된다) 어떤 위젯에서 필요한 데이터가 변화하였다면 이를 감지하여 해당 위젯에게 알려주고, 해당 위젯의 데이터 부분을 업데이트해주어 반응성(Reactive)있는 앱을 만들어준다.

처음 정리하는거라 내용이 좀 복잡한데, 쉽게 한마디로 말하면 아래와 같다.

앱 전체를 가로지르는 데이터 강(스트림)이 있고, 이 강을 관찰하고 있는 관찰자를 하나 세워두어 내가 원하는 데이터에 변화가 있는지 지켜보다가 변화가 생기면 알아서 그 변화를 반영할 수 있도록 위젯을 만든다(스트림 빌더). 이것이 스트림과 스트림 빌더의 개념이다.

내일은 스트림/스트림 빌더 예제 코드를 작성하는 것을 공부해볼 것이다.

예고편

이런 스트림과 스트림 빌더를 보면 UI를 구현하는 코드와 데이터를 관찰하고 처리해주는 스트림/스트림 빌더 영역이 섞이게 된다.
그도 그럴 것이 스트림 빌더에 스트림과 위젯 빌더를 함께 선언하기 때문이다.
스트림/스트림 빌더를 적극적으로 사용할수록 데이터 처리를 담당하는 코드와 UI 코드가 섞이게 되고, 이를 분리하자는 컨셉이 계속 공부하려 했던 BloC 패턴의 컨셉이다.

헷갈리기 쉬운 포인트

BloC, Provider는 모두 디자인 패턴이다! 단순히 상태 관리 패키지라고 정의하기엔 무리가 있음.
디자인 패턴인만큼 이들은 프로젝트 구조를 다루는 분야이며, 이를 쉽게 구현할 수 있도록 구현해놓은 패키지가 각각 bloc, provider이다.
상태 관리와 연관짓게 되는 것은 이들이 반응성을 보장하는 구조이기 때문에, 즉 상태의 변화를 제어할 수 있기 때문이다. 상태 관리 기법/구조/시스템 정도로는 정의해도 괜찮을 것 같다.