useWebRTC 훅의 모듈화가 필요했던 이유

초반에는 모든걸 훅으로 구현 하려다 보니 리액트의 라이프 사이클에 억지로 WebRTC 기능이 들어가 있었다.
그래서 개발을 진행하며 이 상태로는 기능 추가나 버그 픽스가 어렵다고 판단해 모듈화를 진행했다.
리팩토링 후에 서로 의존하는 부분이 많이 해소되었기에 기능추가나 버그픽스시 소요되는 시간이 많이 줄어들것으로 기대하고있다.

훅의 내부가 너무 복잡하다.

코드로 훅 내부를 보면 그냥 보기만 해도 매우 복잡하다.
훅 안의 훅에서 생성된 값을 다른 훅이 인자로 받고 그 후 다른 훅이 그 결과를 다시 받고 마지막으로 모든 처리 결과를 리턴해준다.

글로 작성 하면서도 헷갈리는 기분이다.

의존관계를 그려봐도 정말 복잡하다.

이걸 그림으로 표현 해 봤는데 이해가 이해하기 쉽지만 복잡해보인다.
useControllMedia훅은 세가지 훅을 참조하는데 실행 순서를 잘 지켜줘야 실행이 보장된다.
그리고 세개의 훅은 모두 WebRTC 관련 함수가 필요했는데 따로 나뉘어 있었다.
그래서 기능을 추가 하거나 수정할 때 코드의 흐름을 읽기 어려웠다.

useWebRTC에서 모든걸 처리해주니 Props Drilling도 발생한다.

Props Drilling 문제도 발생했다.
모든 기능을 useWebRTC 훅이 도맡아 처리해주기 때문이다.
때문에 이 훅은 반드시 컴포넌트 최상단에서 호출 되아야 하고, 하단에서 이를 받아서 써야 했다.

그래서 공통적인 부분을 추상화 해주었다.

이 문제들을 해결하기 위해 공통된 로직을 밖으로 아예 빼고 이걸 받아 쓰도록 바꾸었다.
WebRTC는 앱에서 한번만 호출되어야 했기 때문에 싱글톤 패턴을 적용 해 주었다.

그결과 의존관계가 단순해졌다.

처음에 복잡해 보였던 의존관계가 없어지고 훅을 간단히 사용할 수 있게 되었다.
그리고 무조건 최상단의 컴포넌트에서 호출할 필요가 없어져 Props Drilling 역시 해결 되었다.

useWebRTC훅도 단순해졌다.

위의 결과로 인해 useWebRTC 훅은 이제 초라해졌다. 무수히 많은 변수, 함수를 리턴 했었는데 이제 startWebRTC, endWebRTC 함수만 리턴한다.

다시 비교해봐도 정말 단순해졌다.

훅 사용성이 개선되었기에 어떤 훅이 어떤 기능을 하는지 한눈에 파악하기 쉬워졌다. 추가적으로 디버깅, 코드의 추가와 수정 역시 쉬워지게 되었다.

마지막으로 이번에 이렇게 리팩토링을 진행하면서 두가지를 배웠다.

1. 훅을 작성하기 전에는 정말 라이플 사이클 안에 포함되어야 하는 로직인지 생각을 하자
2. 테스트 코드를 반드시 작성하자.

테스트 코드가 없어서 리팩토링을 할 때 손수 테스트를 진행했기에 테스트 코드가 더 와닿았다. 그래서 이번 부스트 캠프 일정이 끝나면 테스트 코드를 제일 먼저 작성할 예정이다.