[TIL] 99클럽 코테 스터디 29일차 TIL : View 레벨 상태관리

📖 오늘의 학습

---

지금까지의 개발: View 레벨의 상태관리

 지금까지의 Flutter 개발을 할 때에는 View 단위로 개발을 하곤 했었다. 상태관리를 View 레벨로 정의를 하여, 내부의 위젯들에 변화가 생기면 전체를 리로드 하는 방식으로 개발을 했다. 이게 권장 사항은 전혀 아니지만, 나름의 장점이 존재한다.

 

View 레벨 상태관리의 장점

 View 레벨로 상태관리를 할 때의 장점은 개발이 굉장히 빠르고 간편해진다는 것이다. 그도 그럴 것이, 위젯 각각이 상태를 가지는 것이 아니라 페이지 하나가 상태를 가지고 그 상태를 해당 페이지 내에서 공유를 하는 방식이기 때문이다. 중앙 집중 방식이기에 이해도 쉽고 코드 짜는 것도 간편해진다. 일종의 MVC 패턴의 성격을 보인다.

 

View 레벨 상태관리의 단점

 그러나 장점이 있다면 단점도 있는 법, 개발이 쉬워진 만큼 퍼포먼스가 줄어든다. 해당 페이지 내에서 아주 작은 변화만 생겨도 페이지 전체를 새로 빌드한다. 부분 리빌드를 해야 렌더링이 줄어들고 효율이 증가하는데, 아주 약간의 변화, 1픽셀의 변화만 일으키는 데이터 변화만 생겨도 페이지 전체를 다시 그려버리게 된다.

 

 다음 단점으로는 위의 방식은 MVC의 성격을 보이는데, 그 중 Controller에 해당하는 부분이 엄청나게 비대해진다. MVC 패턴에서 View와 Controller를 1 : 1로 매칭하기도 하고, 1 : N으로 매칭하기도 하는데, 이게 View라는게 꼭 페이지를 의미하는 건 아니다.(물론 지금까지는 그렇게 의도하고 말하긴 했다.) Flutter에서 의도한 방식은 View = Widget 이기에 각 컨트롤러가 가벼운 대신 굉장히 많아지는 단점이 있었다면, View 레벨 상태관리를 하게 되면 컨트롤러의 개수는 대폭 줄어들지만 줄어든 만큼 엄청나게 비대해지게 된다.

 

 또한 위젯의 상태가 없어 관리가 안된다. 애니메이션을 추가하거나 각각의 위젯이 따로 돌아가는 로직을 짜기가 어려워진다. 그렇기에 굉장히 간단한 어플리케이션이나, 페이지 단위로만 동작하는 기능이 많은 프로젝트에서 권장한다.

 

 

이제부터의 개발 : View 레벨의 상태관리 + 위젯에 상태 부여

 이제부터는 약간의 기교를 넣기 위해 각 위젯에 대해 상태를 넣고자 BLoC 상태관리 패키지를 사용하고자 했다. 허나 문제가 하나 있었으니... BLoC은 각 위젯 별로 상태를 관리하는데, 내가 구현하고자 하는 위젯마다의 상태가 존재하는 프로젝트를 구현할 때 그 상태가 엄청나게 많아진다는 것이다. 게다가 각각의 위젯들이 만든 데이터를 취합하여 서버로 요청을 보낼 때에도 상당히 난감해진다.

 

 그래서 생각해낸 것이 View레벨의 상태관리에 위젯에 대한 상태 Map을 만들어 관리하는 것이다. 성능면에서는 리빌드가 해결이 되지 않아 상당히 자원을 많이 소모하지만, 중앙 집중화를 유지하면서 각각의 위젯이 따로 돌아가는 로직을 짤 수 있게 된다. 위의 수많은 단점들 중 하나만 해결하긴 하기에 프로젝트 구조에 대해 생각을 더 해봐야하겠지만... 일단은 하나를 해결했고 이를 통해 상태를 여러 개 갖는 위젯을 만들 수 있게 됐다.

 

 

🤔 오늘의 회고

---

 프로젝트 구조 짜는게 너무 힘들다. 사수님에게 위젯 각각의 상태를 관리함과 동시에, 각 위젯의 상태를 중앙집중으로 관리할 수 있는 그런 프로젝트 구조가 없을까요? 라고 물었더니, 욕심이 너무 많은거 아니냐는 눈빛으로 보셨다.

 

한 일주일 고민했는데 아직도 못찾아서... 더 고민해보자...