# 멘토와의 만남 :)

### 데모는 어땠나요??

- view만 만들어서 배포를 하였다.
- storybook이 우리의 selling point!

### 저번 주에 했던거 보여줄 수 잇나요??

- css를 재활용할 수 있는 mixin이나 레이아웃을 재활용 할 수 있는 컴포넌트를 잘 만들었다.

### 프론트를 하면서 힘든게 없었나??

- 폴더 구조를 통일함에 있어서 의견이 분분했다.(스토리북)
- 컴포넌트 별로 폴더를 나누기
- 컴포넌트 안에 stories 폴더를 만들기

멘토님 : 답은 없다. 현업에서는 스토리북을 디자이너와 소통하기 위해 같이 사용한다.

- 독립적인 컴포넌트이면 폴더가 따로 있어야 하는게 맞다고 생각(버튼의 경우 여러군데에서 재사용이 가능하다. 실제로 정의되어 있는 디자이너 시스템을 보면 버튼을 따로 컴포넌트로 나눠서 제공한다. 디자이너도 버튼만 보고싶을 수 있다.)

### 프로젝트 기간은 짧은데, 컴포넌트를 재사용성을 고려해서 설계를 해야하는가?

프로젝트 기간이 짧은데 아토믹을 적용하는게 좋을지?
- 실제 회사에서도 아토믹 디자인을 엄격하게 적용하기 보다는 고용ㅇ 컴포넌트를 만들고 최대한 뷰하고 로직을 분리해서 만들고 로직만 주입해서 재사용할 수 있게 많이 만들어 쓴다. 최대한 훅으로 빼버리고 뷰만 관리해서 뷰를 최대한 재활용할 수 있게 한다. 뷰에 로직이 들어가면 재활용하기 힘들다.

### 현업에서는 typescript가 필수적으로 사용하는지?

- 타입 스크립트 자체를 못쓰는 조직이 더 많을 수 있음.
- 예전에 네이버 면접 봣을때 es3 이상 쓸 수 없다고 한적이 있음.
- 오래된 서비스 일 수록 엄청난 레거시가 있을 수 있음.
- let도 못 쓰는 곳이 있음...
- 러닝커브가 그렇게 높지 않다. 그래서 써보는 것도 좋을 것 같다.
- API가 작성되어 있으면 마이그레이션이 어려울 수 있음.
- 도입하려면 API가 많이 작성안된 지금이 마지막 기회일 수 있다.

### 소켓의 메시지 정보를 클라이언트에서 상태로 관리 유무

- 소켓을 사용할 때, 실제로 많이 발생하는 문제
- 1안
-
- 2안
- state로 관리하는 것은 쉽지 않다.
- 비교 관련 문제도 있지만, 더 큰 문제는 많은 state를 가지고 있을 때(10000개의 데이터) 10000개의 데이터를 렌더링 해주기 때문에 문제가 된다.
- state에서 관리하는 데이터를 제한하는 경우가 많다.(최신 순으로 1000개만 보이게 한다. -> 모든 메시지를 확인할 필요가 없을 수 있다.)
- 내가 받아온 데이터를 LOCAL스토리지에(네트워크를 타지 않는다) 넣어 놓고, 내가 보려고하는 스탬프 주변에 데이터를 가져와서 렌더링해서 보여줄 수 도 있음.
- 최신 1000개만 보여줘도 괜찮을 것 같다.
- react diff algorithm을 정확히 알지 못하지만, 비교하는 과정이 필요해 보인다. O(n)을 그렇게 높은 비용이 아니기 때문에 크게 문제는 되지 않을듯(node는 1초에 1억번의 루프를 돌 수 있다)

### 메시지 버퍼(큐)의 유용성

- 버퍼라 하기 보다는 Throttling(자주 사용하는 기술)을 사용하는 문제로 보인다.
- 검색의 자동 완성(마지막 입력 후 500ms가 지나고 api를 호출)에 Throttling을 잘 사용한다.

### 메시지 버퍼의 위치는?

- 서버에서 버퍼를 관리하는건 어렵다.
- 채팅 서버가 여러 개 있을 경우 모든 서버마다 버퍼를 만들고 서버 타이머를 각각 돌려주면서 구현을 해야하기 때문에
- 클라이언트에서 버퍼를 관리하는게 더 쉬움 100줄이면 짤 수 있을 것 같다.
- 클라이언트 자원을 쓸 수 있다면 서버 보단 클라이언트를 쓸 수 있는게 더 좋을 것 같다.
- 기본적으로 TCP 연결하고 socket 통신을 하는 네트워크 비용은 작기 때문에 크게 생각하지 않아도 될 것 같다.

### TDD와 SDD의 범위를 나누는 기준

- ui 테스팅 같은 경우에는 정말 어렵다. 정답이 없다...
- 회사마다 jest를 쓰지 않고, 스토리북으로만 테스트를 하는 경우도 있음.
- jest가 100% 통과해도 컴포넌트가 깨지는 경우가 있음. 심지어 로직도 마찬가지임.
- 페이지 별로 스토리를 만들 경우 필요한 api는 mocking해서 테스트 해보는게 좋을 것 같음
- fetch mocking하는 라이브러리가 있음.
- jest로 테스트하는 것은 어렵다...

- 꼭 해야 한다면 hook 테스트 같은 경우 jest로 해보는 건 좋을 것 같음!

### 메시지 정보를 DB에 저장하는 시점

- 1안을 써도 크게 문제가 될 것 같진 않다.
- 1안을 썼을 때, 유저가 불편함을 느낄 수 있다고 생각하는게 db에 접근하는데 delay가 있을 수 있다.
- 1안을 쓸 때, 사용하는 방식이 낙관적 업데이트를 사용한다.(db가 성공하던 말던 뷰를 먼저 그리고 만약 db가 실패하면 x를 표시해서 서버에 적용되지 않음을 표시하는 방법)
- 2안과 비슷한 방법은 message queue를 쓰는 방식이 있음.(생산자 & 소비자 패턴)
- 유저가 POST를 보내면 서버는 받았다는 메시지만 보내고, 특정 큐에 저장한다.
- 저장된 메시지는 준비된 워커가 있다면 워커가 메시지를 처리한다.
- 직접 구현하기 보다 이미 구현된 큐와 워커를 사용하면 좋겠다.


### 기술은 채택할때 어떤 과정을 거치는지

- 기술을 쓰고 싶은 사람이 열심히 설득하는 것 같다.
- 멘토님은 recoil 좋아하심.
- 세션을 열어 회사 사람들 꼬셔야 함...

### Tip
#### 컴포넌트 만들때 오픈 소스 디자인 라이브러리 참고하면 좋을 것 같음.

- mui, [엔트리 디자인](https://github.com/ant-design/ant-design), [rsuit](https://github.com/rsuite/rsuite)

#### redux는 패턴을 알아야하고, recoil은 hook 사용이라 마이그레이션 하기에 recoil이 더 쉬울 것 같음.

- 연속적인 상태를 관리하기 쉬움. 러닝 커브는 거의 없음.

### 멘토님의 조언

- 충분히 잘하고 있어서 멘토님이 해주실 말이 없다.!