TIL-221208 유사 flex패턴

제대로 사용하고 있지 않았던 플럭스 패턴

 

현재 진행하고 있는 프로젝트에 떡하니 프론트엔드는 플럭스 패턴을 사용한다고 떡하니 써놓아 있다.

 

그래서 store를 만들어서 비즈니스 로직과 상태 관리를 store에서 하고 있기는 한데

 

프로젝트를 진행하면서 상품 상세 페이지 같은 경우는 상품 정보, 리뷰, 문의 사항같은 정보들을 API요청을

여러번 요청을 해서 데이터를 받아온다. 그렇게 받아온 데이터를 스토어에서 관리를 해주는데

 

스토어 및 상태관리를 하고 있는 데이터를 페이지 단에서 선언을 해주고 해당 데이터들을 사용하는

컴포넌트에 props로 전달을 하는 방식으로 진행을 하고 있었다.

 

프롭스가 10개가 넘어가는 컴포넌트가 몇개나 있었다. (이 때 수상함을 느끼고 뭔가 질문을 했어야 했다.)

 

이렇게 하면 문제인게 무엇이냐 상품 상세 페이지를 테스트 할려면

 

상품도 모킹해줘야 하고 리뷰도 모킹해줘야 하고 상품 문의도 모킹해줘야하고

 

인터페이스에 대한 함수도 모킹을 해줘야 해서 페이지 테스트하나가 무려 600줄에 달하게 되었다.

 

모킹만 했는데 테스트가 300줄 가까이 되는 상황이 발생해버린 것이다.

 

플럭스 패턴은 이렇게 상위 컴포넌트에서 모든 데이터를 받아와서 props로 많은 프롭스를 받아오는

이런 불편한 상황 때문에 만들어 진 것 이라는 것을 몸소 깨달아 버렸다.

 

컴포넌트에서 사용할 데이터만 스토어를 통해서 호출을 하면 테스트도 훨씬 줄어들고

페이지 컴포넌트에서는 그냥 렌더링이 되는 정도만 테스트를 하면 되기 때문에 지금보다 훨씬 테스트 코드를 작성하는 시간도 아낄 수 있다.

 

이때 까지 테스트 코드 짜는 데 시간이 너무 오래 걸려서 하.. 안되겠다 일단은 하자 라는 마안드로 TDD를 하지 않고

그냥 진행을 했는데 테스트가 이렇게 많고 조금 만 바꿔도 테스트가 여러개가 깨지는 상황은 이렇게 안좋은 구조를 가지고 있었기 떄문이였다.

 

이게 바로 뭔가 이상함의 신호 였는데 이걸 그냥 참고 하니 그저 고통의 연속이였던 것 이였다.. 

 

 

아... 

 

이제 플럭스 패턴의 장점을 몸소 느겼으니 더 잘 사용할 수 있지 않겠는가?