1 asked

0

좋은 질문입니다.

채팅은 구조상 최초에 테이블 구조를 잡아두더라도 시간이 지나면서 기능이 추가됨에 따라 데이터가 optional하게 추가되는 경향이 생깁니다. 가령 예를 들면 채팅 메시지로 처음 제품은 만들겠지만 채팅에 대해 이모지 응답, 읽은 사람 숫자 등의 메타 데이터, 첨부 파일, 링크 형태, 링크가 있을 때 미리보기를 제공해줄 수 있는 경우 등 온갖 경우의 수가 계속 생기게 됩니다.

그렇다면 생각해볼 점은 서버에 해당 데이터가 어떤 식으로 저장될까라는 점입니다. 그게 중요한 이유는 프론트에서는 결국 서버에 저장된 데이터의 형태를 따라서 후처리하는 방식으로 구현되기 때문입니다.

만약 새로운 기능이 스키마의 컬럼으로 추가되는 형태라면 프론트에서는 매번 해당 컬럼을 추가해주는 방식으로 타입은 맞춰줄 수 있지만 UI에 적합한 표시를 만들기에는 어색할 수 있을 겁니다. 저장된 데이터에 따라 조건부 렌더링이 매우 다양하게 발생하는 경우가 되는 셈이겠네요. 이와 같은 이유로 채팅과 같은 데이터를 프론트에서 표시할 때는 많은 조건부 렌더링을 대응할 수 있도록 구현하고, 이를 어댑터 패턴으로 구현해 맞춤형 디자인을 매칭해줄 수 있습니다.

다만 채팅은 단순히 어댑터를 이용해서 여러 상태에 맞춰 처리되도록 끼워넣기로만 구현하기에는 깔끔하지 않은 측면이 있습니다. 제 생각에는 조건부 렌더링에 대해 "어댑터 패턴 + compound 패턴"을 복합적으로 활용해 처리하는게 복잡한 경우의 수를 대응해줄 수 있을 것 같습니다.