[💌 FEATURE REQUEST] 블록 및 그룹의 추가 로직을 생성한다

[JengYoung]

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

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

배경 및 설명

이제 드디어 대망의 블록-그룹을 UI적으로 CRUD하는 작업에 들어간다. 핵심은 피그마처럼, 드래그를 통해 템플릿에 대한 CRUD 로직을 만들어주는 것이다.

다만 이 작업의 경우, 꽤나 많은 양의 소스코드가 나올 수 있음을 저번 #67 에서 확인했다. (약 3500줄...) 따라서 생성 작업만 우선적으로 만들어 본다.

기대결과

1. [블록]을 누르면 Main 안에서는 crosshair 모양의 커서가 되어야 한다.
2. crosshair 모양인 상태에서 Main 안에 컴포넌트를 그릴 수 있어야 한다.
3. 컴포넌트를 그릴 때에는 예상 가능한 크기가 사각형으로 나와야 한다.
4. 마우스를 떼면 커서 모양이 원래대로 돌아와야 한다.
5. 커서 모양이 돌아옴과 동시에 블록이 나와야 한다.

대안 제시

그러하다. 피그마처럼 하는 로직을 생각하면 된다.

현 상황 - 도입 검토 중

결국 일련의 추가/생성 작업을 한 번에 지원하기로 백엔드 측과 약속한 상태이다. 지금 2가지의 가능성을 검토 중이다.

• TaskQueue 도입 - 형태는 어떤 식으로?
• IndexedDB 도입 - 저장 웹 스토리지는 어떤 것으로?

TaskQueue

TaskQueue를 할 것임은 자명하나, 이를 어떤 방식으로 구현할지가 고민 중이다. 예컨대 그냥 Queue 방식으로 구현하면 다음과 같은 최적화할 부분이 존재하지 않나 고민 중이다.

1. Queue가 서버에 저장되는 순간에, raw하게 데이터를 보내기보다는 압축을 하는 게 더 좋지 않을까? 예컨대 생성-추가-삭제를 모두 했다면 애초부터 컴포넌트가 없는 것이니 요청을 보내지 않아도 된다.
2. 사실 스케줄링을 위한 태스크 큐를 만드는 형식도 굉장히 다양하다. 예컨대 대표적으로 뮤텍스, 세마포어, 모니터 형식처럼 동기화 처리를 위한 태스크 큐의 적용 방식은 다양하게 존재하지만 내부 처리를 좀 더 다양하게 바꾸어줄 수 있다. 어떤 게 나을까?

IndexedDB

이러한 고민은 웹 스토리지 형식에 대해서도 나오고 있다. 예컨대 현재 이런 고민들이 있다.

1. 블록의 생성 로직을 일단 Queue에 놓는다고 치자. 그런데 이거, 새로 고침하면 없어지지 않나?
2. 따라서 당장 떠오르는 건 2가지다. IndexedDB와 LocalStorage인데(Cache API는 PWA가 아니며, 응답 API가 주 캐싱 관심사이므로 일단 논외로 친다.) 어떤 게 나을까?
3. 쉬운 건 LocalStorage이긴 한데, 막상 LocalStorage는 용량 제한이 있지 않나? 그러면 IndexedDB가 낫지 않나?

---

고민 끝에 내린 해답 (230205, 15:00, 최종 결과 아님!)

TaskQueue

되돌리기 등의 여러 로직간의 상호작용을 고려할 때 가장 직관적인 Queue 형식의 태스크 큐를 사용한다. 이유는, 병렬처리가 과연 얼마나 될지 모르는 상황에서 세마포어와 모니터처럼 좀 더 병렬적인 프로세스 처리를 위한 동기화 로직은 오버스럽다는 생각이 들었기 때문이다. (물론 만드는 건 내게 꽤나 귀중한 경험이 되겠지만, 안정적인 코드가 우선이다.)

다만 이러한 방식은 다음 3가지 문제점을 갖고 있다.

• 큐에 추가될 때마다, 업데이트는 어떻게 진행되어야 할 것인가?
• 큐에 추가된 후에는 필연적으로 O(N)만큼의 DOM 업데이트 작업이 일어나야 할 것이다. 이를 최적화하기 위해서는 최적화시킨 큐가 필요하다. 또한 백엔드의 측에서도 최적화된 큐를 전달하는 게 서버의 부하를 덜어낼 방법이기도 하다. 그런데 이는 O(N^2)의 시간복잡도가 필연적으로 발생한다. 그렇다면 이건 오히려 부하를 일으킬 요소가 있는데 synchronization을 어떻게 잘 할 것인가?

일단 전자는 DOM 업데이트를 위한 스토어에 추가하는 함수를 업데이트하여 해결할 수 있다. 그렇다면 우리는 후자가 문제이고, 가장 핵심적인 문제는 최적화된 큐를 어떻게 구현할 것인지가 될 것이다.

🙆🏻 최적화된 큐는 computed되는 형식으로 구축

어차피 되돌리기 등이 일어나면 반드시 큐에서 한 번 연산을 수행해야 한다. 그렇지 않다면 추가적인 로직들을 복잡하게 해야 하고, 이는 적잖은 유지보수성의 문제가 발생한다. (ex: delete를 했다가 다시 되돌리는 경우, 이를 어떻게 돌려 놓는 식을 최적화할 지?)

O(N)으로 일단 최적화된 큐를 만들어낸다. 이때 해당 키(id)가 있음을 알기 위한 스토어를 Map을 사용하여 만들어낸다. 조회할 때마다 있다면 해당 키가 위치한 인덱스 쪽에서 업데이트하는 방식으로 구현하면 O(N)으로 달성 가능하다.

즉 총 로직은 O(N)만으로도 모든 변경 로직을 수행할 수 있는 것이다.

---

추가 고민 후에 내린 해답

TaskQueue - 굳이 내가 최적화된 큐를 만들 필요가 있었나?

생각해보니 멀지 않은 곳에 가장 완벽한 해답이 존재했다. React의 스냅샷 형태의 로직을 이용하면 애초부터 편하지 않았을까 싶다.

결과적으로 사용자가 원하는 결과물은 DOM 형태로 어찌되었든 만들어진다. 그리고 이러한 형태는 Store에 그대로 구현되어 있다.

따라서 스토어에서 각 Block/Group들을 초기의 값과 Diffing하는 알고리즘을 만들어내면 되는 거였다! 그러면 아무리 로직이 복잡해지더라도 간단해진다.

결과 연산 역시 O(N)이겠다.

참고자료

No response