# 질문 목록

1. 프로젝트에서 가장 어려웠던 점은 무엇인가요?
- CRA를 안쓰고 시작했다가 끝에 가서야 성능 이슈를 발견함
- CRA에서 기본적으로 해주던 성능 문제를 직접 옵션을 공부해서 적용해나감
- 아직도 완전한 최적화는 하지 못함
- chunk 파일로 다운 받는거
- nginx에서 압축 파일로 받는 것
- devtools 없애는거
- code splitting
3. 어떤 식으로 협업을 진행했나요?
- zoom 환경
- deadline
- 학습과 구현을 모두 해야한다는 점
- 오전의 스크럼, 문서화를 통해서 해결했다.
- 구현을 하다가 모르겠는 부분을 zoom을 통해서 함께 논의했다.
4. 가계부에서 가장 중요하게 생각되는 것은 무엇인가요?
- 보안적인 서비스
- 사용자 경험
- 시각적 요소가 중요
- 데이터 삽입/조회 위주의 서비스
6. 몽고디비 명분
8. 달력
9. svg
10. 드래그 앤 드랍
- 2가지 과정으로 이루어짐
- 거래내역을 드래그 해 해당 날짜에 드랍하면 수정이 되도록 하는 것
- ondragstart에서 거래내역의 현재 드래그된 거래내역 데이터를 state로 갖고 있도록함
- ondrop에서 state로 갖고 있는 거래내역 데이터를 drop된 곳의 날짜로 변경해서 api 요청, store에서 변경
- 거래내역을 드래그 해 해당 날짜에 hover 하면 미리 거래내역이 들어갈 위치를 보여주는 것을 만드든 것
- 현재 드래그된 거래내역이 어느날짜 위에 있는지를 알아야함
- ondragenter, ondragleave로 구현
- ondragleave가 날짜 컨테이너의 자식 엘리먼트를 지날 때도 호출됨
- ondragleave를 사용하지 않도록 했다.
- 계속해서 다른 곳으로 들어갈 때는 문제가 없음
- drag를 하고 drop 불가 지역에서 놓았을 때 표시하는 엘리먼트가 남아있음
- ondragend에서 초기화를 해줌 dropEffect가 none일 경우만
- 그래도 매우 빨리 갔다 오는 경우 남아있는 문제가 있음
- ondragend에서 어느 때나 초기화를 해줌
- 제대로 된 드랍 지역에 놓았을 때 ondragend에서 초기화를 해주면 state가 바뀌어 렌더링이 다시 된 다음 ondrop에서 store의 데이터를 변경하기 때문에 잠깐의 시간동안 깜빡이는 문제가 있음
- ondragend에서 settimeout을 이용해 일정 시간 뒤에 초기화를 해줌
11. oauth
- client id를 가지고 각 소셜 로그인 사이트로 이동
- 해당 사이트에서 사용자가 로그인 진행
- 로그인 이후에 정해진 redirect url로 리다이렉트
- 해당 사이트에서 url과 함께 보내진 code를 읽어 서버로 요청을 보냄
- 서버에서 code와 client id, client secret을 가지고 access token 가져옴
- access token을 가지고 사용자 정보를 가져옴
- 사용자가 서버의 db에 있는지 확인, 없으면 넣어줌
- access token 발급
- 클라이언트로 반환
- 어려웠던 점
- 처음에 code를 가지고 각 소셜 로그인 사이트로 바로 요청을 보냈으나 cors 오류.
- 표준이 없어서 두 사이트가 조금씩 다른 부분이 있어서 한 함수로 처리하지 못함
12. csv import export
- Export 과정이 어떻게 되나요?
- 몽고DB의 데이터를 백엔드에서 csv파일로 가공한 후 FE로 보내주었다.
- 다운로드 받을 수 있게 blob 파일을 createElement('a')로 생성하여 다운로드 옵션을 주었다.
- Import 과정이 어떻게 되나요?
- Client가 Import 하고 싶은 csv파일을 첨부하면 useState로 setFile 해준다.
- csv 파일을 json형태로 서버에 보내준다.
- 서버에서 JSON.parse()로 배열형태로 바꿔준 후 mongDB에 맞는 객체로 가공해준다.
- 형식에 맞지 않는 key값이나 필드값이 비어있다면 error를 던진다.
- 구현 시 어려웠던 점?
- 원래는 csv파일을 첨부하면 통째로 백엔드에 보낸 후 백엔드에서 모든 가공을 하고 싶었지만 csv 파일의 내용을 보기위해선 FE에서 열어서 보내지 않으면 백엔드에서 파싱할 방법이 없어서 어려웠다.
13. 가계부 목록 페이지 질문
- .
14. 메세지 파싱
15. Token
- Access Token, Refresh Token 사용
- Access Token 만 사용하는 것은 토큰 탈취의 가능성이 있어 Refresh Token을 사용했다.
- Refresh Token의 관리
- Access Token이 만료될 시 Client측 에서 Refresh Token을 보내줘야 했다.
- 따라서 Client 측에 보관하기로 결정했다.
- 여러가지 보관 방법이 있겠지만, 우선 Local Storage에 보관하기로 했다.
- 보완할 수 있는 방법
- Refresh Token의 탈취를 방지하기 위해 "로그아웃"이나 "토큰 만료시"DB에 Refresh 토큰을 Black List로 관리하여 탈취된 토큰으로 접근시 막는다.
- Sliding Session 방법을 사용하여 Access Token 이나 Refresh Token에 적용한다.
- 가계부는 입력 텀이 짧은 서비스 이기에 Refresh Token에 적용하는 것 보다는 Access Token에 적용하는 것이 좋을 것 같다.
- Refresh Token의 보관방식을 변경한다.
- Auth Server와 Resource Server를 분리한다. 그리고 Refresh Token 을 Resource 서버에서 가지고 있다가, Access Token이 만료될 시 Auth Server에 전송하여 새로운 Access Token을 받아오고, Client에 보내준다.
- Resource 서버에서는 Refresh Token과 Access Token에 대해서 관리 해줘야 할 것 같다. Auth 서버에서는 Refresh Token의 블랙리스트를 관리해준다.
16. TS
- TS를 적용했을 때 좋다고 생각한 부분
- 매개변수나 반환 값의 타입을 지정해 줌으로써, 미연에 방지할 수 있다.
- 어려웠던 점
- ㅇㄹ
17. koa
- Express 랑 차이점?
- 느낀점 빌드업
18. mongo db
- ㅇㄹ
19. 3d 캐러셀
- ㅇㄹ

21. 라이트모드 / 다크모드
- ㅇㄹ

23. URL에 정보 표기하지 않았을 때의 문제점
- ㅇㄹ

25. MobX 질문
- 차이점
- store를 여러개 만들 수 있다.
- mutable 하게 수정 가능
- 상태관리 라이브러리의 장점?
- depth가 깊은 컴포넌트 사이의 state와 method 접근이 복잡해지는 문제를 해결할 수 있다.
- 컴포넌트에 집중된 비즈니스 로직을 분리할 수 있다. 컴포넌트가 컨트롤러 같은 역할을 하고 나머지 비즈니스 로직은 분리해서 관리할 수 있다.
26.