# Group 15 피어세션

## 궁금했던점 & 고민했던점

- infinity scroll 구현 시 매번 DB에 api요청 vs 한번에 모두 갖고 온 후 나눠서 렌더링
- 데이터 양의 차이가 확연한 것이 아니라면 직접 실행해서 성능 차이를 확인하는 것이 좋아보인다.
- 한 번에 모든 데이터를 갖고 오는 것보다 조금씩 필요한 만큼 가져오는게 좋을 것 같다.
- 한번에 필요한만큼 가져오는게 아니라 여유분을 불러와서 캐싱하는 방법도 좋은 것 같다(https://github.com/vercel/swr).

- 클라이언트 사이드 라우팅 어떻게 구현하셨나요? -> 저도 궁금해요
- 페이지 컴포넌트를 만들어서 push/popstate 될때마다 화면변경
- 라우팅 경로의 변화가 발생할 시 template을 만들어서 덧붙이는 방법

- 옵저버패턴 어떻게 구현하셨나요? 저는 side effect가 일어나네요...
- 구현 못했어요 ㅠㅠ
- 옵저버를 여러개 만든다.
- 하나를 만들어서 여러 스토어에 적용한다.
- redux의 구조를 참고하여 구현했다. redux는 전역에 스토어가 하나 존재하지만 편의상 전역에 여러 스토어를 만들어 사용했다.

- 상태관리에 대한 고민 ... 얼마나 많은 정보를 어떻게 다루는 지 ..
- 다른 컴포넌트에 영향을 주는 상태들은 글로벌 store에서 보관하고, 각 컴포넌트 내에서만 사용하는 상태들은 컴포넌트 내 로컬 state로 저장해 사용했습니다.
- 그냥 유저 아이디랑 지역 정도 객체로 저장했어요. 프론트에서는 크게 저장할게 없다고 느꼈어요!

- 프론트 / 백엔드 폴더를 나누는 구조의 장점이 뭘까요
- 합치면 파일들이 어디있는지 헷갈림
- 역할의 구분이 분명하여 분업에 좋고 원하는 파일을 수월하게 찾을 수 있다.
- npm workspace 라는게 한 저장소에서 프론트/백엔드 디렉토리를 나눠 작업할 수 있는 기능을 지원함

- 데이터베이스를 설계할때, 목록 조회 api & 상세보기 api -> 테이블을 나누는게 옳은가?
- 데이터 중복이 너무 많을 것 같아 좋진 않을것같다
- api마다 구분할 필요가 없다
- 무조건 select * 하지않고 필요한 정보만 가져오면 된다
- nosql에서는 이렇게 해도 될 수도 있지 않지 않을까..?

- 개발환경 설정: webpack-dev-server 사용할 때 서버와 다른 포트에서 돌아가서 쿠키 설정을 못해주는걸 너무 늦게 알아채서 시간을 많이 허비했습니다. 다들 개발환경 구성은 어떻게 하셨나요?
- 프론트와 백을 나누지 않기도 하고 webpack-dev-server를 적용하지 않아서 접하지 못했다.
- webpack-dev-middleware 사용하면 해당 이슈가 해결될 것 같다.
- 백에서 토큰형식으로 프론트에 세션id를 보내고 프론트에서 세션을 감싸서 전송하는 방식으로 구현했다.
- 환경 별로 환경설정 파일을 따로 두어서 구현했다.
- webpack의 watch 옵션을 이용하는 방법도 있음.

- 타입스크립트 사용시 어쩔수없는 any / 명시적으로 타입 안써주기 사용은 어디까지 허용해야 좋을까요?
- 정말 타입을 어떻게 못한다 -> any 보다는 unknown 을 쓴다고 함.
- 타입스크립트를 사용하는 목적이 협업을 위한 것이므로 일부러 타입을 써주는게 이득일듯

- 이미지 컨테이너에 1px 삐져나오는 흰색 이슈
- reset.css를 먼저 적용해보면 좋을것 같아요
- 원본 이미지가 불량인가?
- image-background 속성을 사용해보셔도 좋을듯 합니다

## 캠퍼
| 캠퍼 ID | 이름 |
| ---- | ----- |
| J010 | 권윤영 |
| J038 | 김영수 |
| J046 | 김유석 |
| J066 | 김현민 |
| J097 | 방규빈 |
| J146 | 이영범 |
| J172 | 임성빈 |
| J178 | 장진희 |