Flux 구조에서의 상태 관리 책임의 분리

 

엊그제 운동 참가 신청 최소 기능을 구현하는 과정에서 고민했던 부분이 있었다. 신청 버튼을 누르면 API 서버에 POST 요청을 보내고, 응답으로 신청된 경기의 식별자가 있으면 게시물 목록을 다시 가져오게 하려고 했다. 상태 하나를 저장하기 위해 굳이 Store까지 만들어야 할까 생각이 들어 페이지 컴포넌트가 바로 API 요청을 호출하면 안 되는지 질문을 올렸다.

 

또 한번 강의에서 배우지 않은 내용대로 하려고 했음을 인지하고 Store에서 API를 호출하고, 응답으로 돌아온 신청된 경기의 식별자를 Store에 저장한 뒤 페이지 컴포넌트에서는 Custom hook으로 Store가 들고 있는 상태에 접근하도록 했다.

 

 

물론 비동기 처리만 해 주면 페이지 컴포넌트가 API를 바로 호출하게 해도 문제는 없다. 그런데도 왜 컴포넌트가 API에 바로 접근하게 하지 않고 Custom hook을 거쳐서 Store에서 전역으로 상태를 관리하고, Store에서 API를 호출하는 레이어에 접근하게 할까?

 

안 좋은 점은 무엇일까? 페이지 컴포넌트는 Store에서 변경된 상태를 받아와 UI 컴포넌트에 전달하는 책임이 있다. 내가 하려고 했던 것처럼 페이지에 API를 호출해 응답을 받는 역할이 추가된다면, 페이지 컴포넌트의 역할에는 Action을 전달받는 책임이 더해지게 된다. 따라서 페이지의 복잡도가 높아진다.

 

만약 API를 호출해 응답을 가져오는 인터페이스가 바뀌게 된다면 페이지도 수정되어야 하고, 그 과정에서 UI 컴포넌트에 전달되는 로직에 영향이 갈 수 있다.

 

그렇다면 페이지에서 Custom hook으로 Store에 접근하고, Store가 Action을 전달받는 구조를 생각해보자. 이제 UI와 페이지, 상태 관리와 Action 수신의 책임이 각각의 레이어로 분리되게 되었다. Action을 수신하는 인터페이스가 변경되어도 페이지가 Store와 연결되는 Custom Hook의 인터페이스의 형태가 동일하다면 페이지 컴포넌트의 로직에는 직접적인 영향이 없다.

 

즉, 상태라는 비즈니스 로직을 UI라는 컴포넌트와 구조적으로 분리해 관심사를 분리시키는 것으로 볼 수 있겠다.

 

한편 레이어가 각각의 책임을 맡게 하는 것은 각 레이어의 단위 테스트를 작성하기 쉽게 만들 수 있다. UI는 페이지로부터 전달되는 propertie들을, 페이지는 Store에 접근하기 위한 Custom Hook을, Store는 전달되는 Action으로 주어지는 데이터를 모킹하는 것으로 테스트를 위한 데이터를 직관적으로 구성할 수 있다.

 

 

 

Reference

- https://www.youtube.com/watch?v=wQFBgKl1PYw 

- 노아 트레이너님