[Refactor] Context API를 통한 mediasoup 관련 로직 분리

[seoko97]

관련 이슈 번호

• close [Feat] mediasoup 로직 context api 로 분리 #251
• close [Feat] 방 종료시 stream, producer, transport, consumer 클린업 #265

작업 내용

• 기존 hook으로 관리하던 상태 정보를 context api를 통해 관리하도록 변경
• transport, local stream, remote stream 별 context 분리
• 동시 입장시 동일한 consumer를 2개 생성하던 오류 수정

고민과 학습내용

초기 생각한 구조는 다음과 같습니다.

1. Reducer를 통해 각 기능별 상태 관리 및 액션 중앙화
2. Context API를 통해 state, action을 provider 내부에서 사용 가능하도록 선언

기존 useState + useRef 구조와 비교하면 다음과 같습니다.

특성	useReducer	useState + useRef
복잡한 상태 관리	✅ 상태가 복잡하거나 여러 상태가 연관된 경우 유리	❌ 여러 상태가 연관된 경우 관리가 어려울 수 있음
간단한 상태 관리	❌ 단일 상태나 간단한 상태 변경에 과도한 방식일 수 있음	✅ 간단한 상태 변경에 최적화
상태 변경 추적	✅ 액션과 리듀서를 통해 명확히 추적 가능	❌ 값 변경 추적이 어려울 수 있음
디버깅 용이성	✅ 상태 변화가 명확하고 추적이 쉬움	❌ 값 변경 추적이 어렵고 상태가 분산될 수 있음
렌더링 최적화	❌ 상태 변경 시 컴포넌트가 항상 재렌더링 됨	✅ useRef로 상태를 변경해도 컴포넌트 재렌더링 방지 가능
보일러플레이트 코드	❌ 코드가 상대적으로 많고 복잡함	✅ 코드가 간결하고 간단함

useReducer를 통해 구현을 완료하고 테스트를 진행하던 와중 우선적으로 실행한 dispatch가 선언된 함수의 평가 이후 실행되는 것을 확인했습니다.

dispatch나 setState에 경우 상태 업데이트 즉시 업데이트된 상태 값을 참조할 수 없으며 React 렌더링 사이클에 따라 useEffect를 통해 해당 상태를 트리거하는 방식을 사용해야 합니다.

socket과 reducer를 함께 사용할 경우 해당 함수의 변경이 어디서 이루어졌는지 제대로 확인할 수 없어 기존 useReducer를 걷어내고, useRef + useState를 사용하는 것으로 변경하였습니다.

useRef에 경우 setState나 dispatch와 달리 상태가 변경되는 과정을 기다릴 필요 없이, 동일한 함수 레벨에서 즉시 최신 값을 참조할 수 있습니다.

따라서, UI에 실제로 반영되지 않는 socket, transport, producer 등을 ref에 등록하고 remoteStream 같이 실제로 UI에 반영되는 상태는 state에 저장하여 로직을 구현했습니다.

[github-actions]

🎨 스토리북 확인하기

• 👀 Preview
• 🔍 Build Details

[simeunseo]

context로 상태를 빼니 훨씬 가독성이 좋아진 것 같습니다 👍👍👍👍
그리고 기존처럼 consumerstream과 producerstream으로 나누는게 아니라 localstream과 remotestream을 기준으로 hook을 나눈것도 더 적합한듯합니다.

고생정말 많으셨습니다!

[begong313]

👍🏿