채팅 화면 구현

[guesung]

[guesung]

구조

Header, ChatMessageList, ChatInput으로 3등분하였다.
Header는 고정이고, ChatMessageList는 메인 페이지(Server Component)에서 채팅목록을 상시 전달받아 렌더링하면 된다. 그리고, ChatInput은 사용자가 input을 입력하여 send버튼을 누르면 전송하면 된다.

[guesung]

고민 1. Sementic 태그는 어떤걸 사용하는 게 좋을까?

검색 최적화가 필요 없는 사이트이기에(웹뷰이기에) html구조를 지킬 필요가 없을까?
우선, SEO에 최적화된 Sementic Tag 구조는 다음과 같다.

우선, Header는 <header />를 사용하고, ChatMEssageList는 <article>을 사용하도록 해야겠다.

[guesung]

고민 2. Input의 state는 ChatInput 컴포넌트 안에서 관리하는 것이 좋을까, 바깥(Server Component)에서 관리하는 것이 좋을까?

Server Component에서는 useState를 사용하지 못한다.
ChatInput에서 데이터 입력 -> stream값, 결과값 전달받음 -> 상위 컴포넌트(Server component)에 올려서 -> ChatMessageList 컴포넌트에 다시 내려야 함

방법 1. 바깥 컴포넌트를 Client Component로 바꿔 useState를 부모 컴포넌트에서 선언하고, 각 자식 컴포넌트에 state와 setState함수를 넘겨준다.
방법 2. Context API 등 전역 상태 관리 라이브러리를 사용한다.

[guesung]

2번에서, 그렇다면 어떤 상태 관리 라이브러리르 사용하는 게 좋을까?

1. Context API : 컴포넌트 트리 전체에 데이터를 제공. React 내장 라이브러리
2. Redux : 이미 검증된 신뢰성 있는 라이브러리. Redux Devtools를 이용해 직관적으로 상태값 변경 확인 가능 -> 전역 관리 상태값이 많아질 경우 디버깅이 편함. 순수함수로 되어 있어 상태 예측이 가능
3. Recoil : useState훅처럼 직관적이고 간단한 구조를 가짐
   나는 많은 상태를 관리할 것이 아니고, '채팅 목록'만 관리하면 된다. 이 한 state를 위해 Redux를 사용할 필요는 없어 보인다. 그렇다면 Recoil은 어떠한가?

[guesung]

Context API는 Provider하위의 모든 consumer들이 Provider속성이 변경될 댸마다 다시 렌더링된다. 내가 사용할 Provider의 값이 배열(채팅 내역)인데, 구조가 조금이라도 변경된다면 그 Context를 구독하고 잇는 하위의 모든 것들이 다시 렌더링 된다. 그렇게 된다면 너무 많은 렌더링이 일어날 것으로 예상이 된다.
관리할 state가 한 개이기도 하고, 간단한 구조를 가진 Recoil을 사용하기로 결정하였다.

[guesung]

recoil을 이용하여 구현하였다. stream 메시지를 받을 때마다 렌더링이 일어난다. 메시지를 받고 있는 말풍선은 re-rendering이 일어나는 것이 맞는데, 다른 컴포넌트에서 일어나는 렌더링은 불필요하다.