[💌 FEATURE REQUEST] 템플릿 만들기의 전역상태를 추가한다

[JengYoung]

멈춰! 🖐🏻 잠시 체크 들어갑니다~

• [X] 다음 페이지에서 중복되지 않음을 확인했어요. 🙆🏻
• [X] 다른 분들께서 허락해주신다면, 제가 구현해보고 싶어요! 🙆🏻‍♀️

배경 및 설명

조만간 Resize와 Draggable을 구현하려 한다. 이를 조작하기 위해서는 상태가 필요한데, 사전에 이를 전역에서 관리하고자 한다.

이유는 다음과 같다.

1. 컴포넌트의 스타일 상태는 메인 뿐만 아니라 왼쪽 사이드바/오른쪽 사이드바에서 영향을 끼친다.
2. 최상위에서 상태를 내려주는 것은 결과적으로 전체를 리렌더링하는 로직과 다를 바가 없다. 이유는 리액트에서는 부모의 state가 바뀌면 자식도 리렌더링되기 때문이다.

기대결과

전역 상태를 정의함으로써 렌더링 로직을 최적화할 수 있다. 전역 상태를 정의하여 다른 계층에 존재하는 컴포넌트 역시 해당 상태에 대해 반응할 수 있도록 제어할 수 있다.

대안 제시

초기 설계를 잘해야 한다.

며칠 고민하지 않았지만, 피그마 로직은 생각보다 복잡한 것 같다. 그도 그럴 것이 사실상 내가 새로운 컴포넌트를 화면 상에 그려내야 하기 때문에, 설계를 대충 해버리면, 나중에 수정하기가 매우 어렵다.

왜냐하면 컴포넌트의 종류는 무궁무진하며, 따라서 확장에는 열려있어야 하는데, 이에 대한 패턴 설계가 제대로 되어 있지 않으면 유지보수가 굉장히 어려워지기 때문이다.

TaskQueue 생성?!

따라서 일단 일감은 blockGroup에서 어느정도 State를 가져오는 건 Store 덕분에 해결한 것 같은데 문제는 어떻게 요청을 처리하느냐다. 일감은 TaskQueue도 생성해야 할 것 같다.

이유는 HTTP 통신에 있어 계속 요청/응답을 각 컴포넌트 변경시마다 하면 네트워크 간 통신에서 발생하는 트래픽이 생각보다 만만치 않을 것 같다는 생각이다.

이유는 다음과 같다.

• 한 번 수정할 때마다 한 번 요청이 간다.
• 만약 1000개를 감싸고 있는 최상위 그룹에서 하위 블록/그룹을 다 뺀다고 생각해보자.
• 그럼 한 클라이언트에서 요청이 1000개 들어가므로 백엔드 입장에서 응답을 하는 데 쓸데없는 리소스를 써야 한다.(헤더도 추가하고 토큰 검증 등의 chores를 해야 하기 때문) 이건 매우 비싸다.

또한 이렇게 한꺼번에 여러 개의 요청을 처리하는 로직은 Virtual DOM(실제로는 리액트는 이제 이 말을 싫어하긴 하지만)의 대명사인 리액트에서 처리하는 방법이기도 하다. 리액트는 상태 변경이 발생하면 약 10ms ~ 20ms 내의 처리 시간에서 발생한 상태 변경 로직을 모아 배치 처리한다.

이렇게 비동기 처리를 한꺼번에 배치처리함으로써 빠르게 상태를 반영할 수 있는 것이다. 아직 백엔드 쪽에 요청하지는 않았지만, 디바운스 후, 이러한 일괄 요청 방식에 대해 검토하도록 제안해야겠다.

참고자료

리액트 배치 처리에 대한 근거를 찾다가 완벽하진 않지만 일단 보이는 걸 찾았다