[개발 기록] Fake Talk (3) - redux의 소중함을 깨달았다

오늘은 메시지 수정, 삭제, 유저 이름 수정 기능을 구현했다.

 

1) 처음엔 수정할 chatItem의 id를 찾아 item.message만 변경해줬는데 수정된 내용이 렌더링 되지 않았다. 생각해보니 리액트가 state를 이전 상태와 비교할 때 객체는 변경되지 않고 안의 내용물만 변경되었으니 다시 렌더링 하지 않았던 상황이었다. 이를 새로운 객체로 대체해주어 해결했다.

 

2) 분명히 컴포넌트가 7개밖에 안 되는 작은 프로젝트인데도 state 관리하기가 너무 귀찮았다.

부모 컴포넌트에 2~3개의 자식 컴포넌트가 들어가고, 그 컴포넌트 안에서도 2~3개씩 자식 컴포넌트가 존재한다. 근데 자식 컴포넌트 사이에서 state를 공유해야 할 일이 생기니 공통 부모 컴포넌트마다 state가 생기고, 그에 따른 state 변경을 다루는 함수들도 생기는데, 이걸 전부 props로 넘겨줘야 해서 코드가 점점 복잡해졌다. 컴포넌트가 더 많아질수록 state 분기도 늘어나 관리하기 빡쎌 것 같았다. 상태 관리 툴을 사용하지 않고 코딩하다 보니 왜 그런 툴을 쓰는지 단번에 이해하게 되었다.

 

3) 한 컴포넌트에 onclick, onDoubleClick 이벤트를 한 번에 걸었더니 하나가 작동하지 않았다. 검색해보니 DOM에서 원래 두 이벤트를 동시에 지원하지 않는다고 한다. 프로젝트가 끝나면 웹 관점에서의 바닐라 자바스크립트 관련해서도 더 깊게 공부해야겠다.

 

4) 프로젝트에서 ChatItem 관련해서는 id를 받아 수정, 삭제 등을 하고, User 관련해서는 유저 객체를 통째로 받아 수정, 삭제 등을 한다. 프로젝트를 진행하면서도 계속 이게 맞나.. 고민을 많이 했다. 이번에 유저 이름 수정 기능을 구현하면서 깨달았다. 유저 이름을 수정할 땐 map으로 새로운 객체를 반환해주도록 구현했는데, ChatItem에 유저 객체를 통째로 넣어놓은 바람에 유저 이름을 따로 수정해도 item에 들어있는 객체는 변경되지 않아 메시지의 이름은 그대로 남아있었다. 이렇게 된 김에 user id를 이용해 렌더링 시 user정보를 갖고 오는 방식으로 변경하기로 했다.

 

아래는 현재까지 진행 상황이다!

 

 

오늘 한 일

• 메시지의 수정, 삭제, 유저 이름의 수정 기능 구현

 

이슈 하나 처리하면 추가 이슈가 두세 개씩 더 추가된다... 처음부터 완벽히 기획하지 않아서 벌어진 일 같다..

 

남은 일