[Retrospect] 3주차 회고 - 권민재

Template Content
# 권민재

### Fact (사실)
- 각 페이지에 기능을 입히고 CSS 작업을 했다.

### Feeling (느낌)
- 이전에 미처 기능이라고 생각하지 못했던 부분들이 굉장히 중요한 기능일 수도 있다는 것을 깨달았다. 직접적인 DOM 조작을 하지 않으면서, react hooks, styled-component, atomic pattern 으로 구성된 컴포넌트들에 UI 변화를 주려니, 생소함 때문인지 더 까다롭게 느껴지기도 했다.
- 예컨대, 이전 프로젝트에서는 classList.add/remove 등을 활용해서 토글같은 효과를 주었다면, 이번에는 useState 로 컴포넌트의 상태변화를 추적하고, 그에 따라 다른 styled component 아이템을 렌더링하는 방식으로 구현해야 했다.
- 같은 방법으로 toggle 뿐 아니라, hover 효과도 줄 수 있었다. mouse event 에 따라 useState 를 변경하여 hover 상태를 추적한 후, 역시 그에 따라 다른 styled component 를 렌더링하면 되었다.
- 아토믹 패턴의 기능 컴포넌트들은 그 역할에 따라 organisms, molecules, atoms 폴더에 나누어져 있는데 단순히 top-down 형식으로 컴포넌트들이 쪼개져 있다는 개념을 넘어, 각 컴포넌트들이 상태값으로 관리하는 데이터들도 다르기 때문에 그에 맞추어 상태 끌어올리기를 할 지, 리덕스를 사용해야 할지, 혹은 data-* 와 같은 속성을 넣어서 핸들링해야 할 지 결정해야 했다.

### Finding (교훈)
- 모든 컴포넌트들에서 공통적으로 접근할 필요성이 있는 상태값은 리덕스에 넣는다. 라는 전제로 리덕스 사용을 시작했다. 그래서 로그인 정보를 리덕스에 담아 관리했는데 새로고침을 하면 리덕스 상태값도 새로고침이 되는 현상(!!)이 발생해서 결국 로컬스토리지를 사용했다. 로컬스토리지를 사용하지 않는 방법이 있을지 궁금하다.
- 프로젝트를 마무리해가는 주라 그런지, 프론트엔드는 디테일에 강해야 한다는 것을 새삼 느꼈다. 예컨대, submit 후 이전 데이터 값이나 UI 세팅을 다시 되돌려 놓아야 한다든지.. 그런 것들. 아침 저녁으로 팀원들과 미팅하며 유저테스트를 해보면 꼭 뭔가가 튀어나왔다. 보편적으로 어떤 에러들은 특정 방식으로 처리되어야 한다는 기대치가 있는데 (예컨대, 로그인하지 않은 사용자가 리뷰 입력창에 포커스했을 때 로그인을 하도록 요청한다든지), 이렇게 다양한 사용자가 시도할 법한 에러 유발 가능한 행동들을 얼마나 잘 예측하고 방어해두느냐가 프로덕트 완성도의 차이를 가져온다는 것을 느꼈다.

### Future action(행동)
- 로컬스토리지를 사용하지 않고, 즉 새로고침 후에도 로그인 정보를 유지할 수 있는 방법에 대해 리서치해 보아야겠다.
- 이번 주에 느낀 점을 포함하여 프로젝트 동안 배운 점에 대해 회고 블로깅을 할 것이다.