-
Notifications
You must be signed in to change notification settings - Fork 5
With 신안우이(Web19)
Harry edited this page Nov 21, 2021
·
1 revision
번호 | 이름 | GITHUB |
---|---|---|
J137 | 윤해수 | @haesoo9410 |
J164 | 이찬호 | @ChanHoLee275 |
J119 | 안병웅 | @gomster96 |
J113 | 신우진 | @gintooooonic |
J155 | 이인송 | @ingong |
J066 | 김현민 | @rudy3091 |
J127 | 우재석 | @JaeseokWoo |
J152 | 이유노 | @Florallife |
- 디자인 시스템 기반의 컴포넌트 제작 (버튼, 모달, 아이콘, 드롭다운)
- 공용으로 사용할 전역 변수 설정
- 전역 context provider 작성
- 개인의 태스크를 화면에 출력
- 자주 사용되는 로직 Hook 들을 CustomHook 으로 작성 후 사용법 공유
- 문서화
- 커스텀 훅
- context api를 효율적으로 관리하기 위하여 hooks을 작성
- useCallback hook으로 감싸서 함수를 계속 정의하는 것을 막음
- socket instance를 전역으로 관리하기 위해서 최상위 컴포넌트에서 socket 연결을 한다!
- 여기서 공부해보세요!
- 상태관리에 대한 수많은 고민...
- Immer (매우 간단하지만 도입을 결정했던 이유를 공유하면 좋을 것 같아요)
- context에서 상태는 불변성을 지키는 것이 좋음!
- deep copy를 해야 하는데 그냥 immer를 사용하는 것이 편할 것 같아서 사용!
- 상태관리 라이브러리를 사용하지 않고 Hook 만으로 상태 관리
- jsdoc 주석
- 협업 할 때, 선언한 함수들에 대한 설명을 작성하면 사용할 때 편함.
-
커스텀 훅 사용한 코드 보고싶습니다
- 넹
-
커스텀 훅을 만드는 기준이 따로 있나요?
- 자주 사용될 것 같은 거는 일단 만들어놓기!
- 컴포넌트와 로직을 분리해서 테스트에 용이하게 사용할 수 있음!
-
상태관리 라이브러리를 사용하지 않고 contextapi를 사용하신 이유가 있으신가요
- 상태관리 라이브러리의 장점을 체감하기 위해서 context api를 사용
- recoil 또는 redux로 마이그레이션 작업 예정!
-
Hook만으로 상태관리를 하면서 느꼈던 장점, 단점
- 장점은 없습니다.
- 상태관리를 전체적으로 사용하기 렌더링이 전부 되기 때문에 단점!
- 비동기를 할 때, 사용하기 어렵다(redux의 middleware를 못쓴다...ㅠ)
- 결국 비동기 로직 처리는 컴포넌트 내부에서 해야됨
- 단점은 있다!
-
아까 보니까 디자인 너무 깔끔하던데.. 디자인 담당이 있었나요
- 2주를 갈아 넣었습니다.
- 작은 디자인 원칙을 둠
- 버튼 내부 텍스트는 bold
- 모든 border radius를 통일
- 그림자를 쓸 때는 어두운 배경에만 그림자를 사용 (흰 배경 + 흰 컴포넌트에 적용하면 어색)
- 직접 디자인을 하셨는데 퀄리티가 굉장합니다.
- 프로젝트 확실하게 배워가며 세팅하신게 너무 멋지고 대단해요.
- 게시글 검색 기능 구현
- 검색어와 필터링 옵션에 따른 검색 API
- 데이터베이스 인덱싱
- 검색 필터 옵션을 쿼리스트링으로 관리
- 게시글 작성 기능 구현
- 게시글 상세 페이지 구현
- SSE(Server-Sent Events)로 서버 시간 가지고와서 마감 시간 출력
- 팀 학습 노트 관리 (GitHub Wiki)
- 메인 페이지 디자인 리뉴얼
- 무한스크롤
- ref를 써서 intersection observer 사용
- 마지막 div 엘리먼트 observe 하면 요청을 보내도록 구현
- createQueryString 유틸함수인가요 신기하네요
- 새로운 글이 올라오면 무한스크롤 과정에서 같은 글이 보일것 같은데 안그런가요??
- 맞아요 계속 같은 글만 보여요.....
- postId를 기억해 놓았다가 다음번에 것을 확인할 때 참조하여 이 다음 postId 부터 계산하기
- (스크롤위치/전체높이) 의 퍼센트로 구분하지 않고 옵저버를 사용하신 이유가있나요?? 스크롤 위치가 약 90%일때 요청보내는 식으로 해도 비슷하게 동작할 것 같아서요.
- 스크롤 이벤트가 너무 자주 실행되므로 비효율적
- 쿼리 최적화 했던 과정
- 기존의 쿼리 방식을 바꾸기
- 원으로 반경 1km 가져오는 것에서 사각형을 그려서 가져오기
- 카디널리티가 높은 순으로 인덱스 적용 (위도, 경도)
- 기존의 쿼리 방식을 바꾸기
- material ui는 안 무겁나요?
- 사용하긴 했는데 전체에 대해 x
- 부분부분 사용
- 버튼같은 컴포넌트 위주로 사용
- drawer 같은 것들
- 많이 사용한건 아닌데 performance 측정은 아직 해보진 않았습니다만 불편한건 체감x
- 상태관리 어떻게 하시나요?
- 라이브러리 recoil 사용중
- 위치를 받아올때 (geolocation) 저장
- 게시글 작성할때, 검색해줄때 recoilstate 를 통해 이뤄짐
- recoil 사용은 기획단계에서 기술스택 정할때 고민하다 코드양이 줄어들고 hook을 사용해봤으니까 간편하게 적용할 수 있을것같아 선택함
- 테스팅....하셨나요?(아련하네요..)
- 하기로는 했다
- 전체를 다 테스트하기엔 시간이 없을것 같아 기능별로 부분적으로 적용해보려 함
- TDD를 적용할만한 기능을 고민중이다.
- 스토리북 도입 계획이 있으신가요?
- 개발기록을 남기신 것이 너무 멋져서 논의를 할 예정입니다.
- 아까 쿼리 최적화 발표 내용을 잠깐 들었었는데, 한 번 더 설명해주실 수 있나요?
- 녭
- Redis 어디에 쓰셨는지!
- 아직 안썼습니다! 처음에 로그인 세션을 관리하려고 쓸까 하고 넣어놨는데 아직 사용할지 말지 고민중입니다.
- 상태관리
- Recoil
- 더미데이터 넣은 방법이 궁금합니다.
- script를 짜서 돌렸음
- csv 파일을 만들어서 넣어줬음
- userId를 5개 주고 난수 돌리고 인덱스 가져와 넣어줌
- content는 노래가사 넣어줌
- 고려했던 사항이 검색할때 text검색할때를 위해 키워드같은거들을 넣어줌
- 테스트할때 일반적인 상황을 연출하기 좋았음
- json2csv 모듈 사용
- csv파일을 node script.js > data.csv 로 파이핑하여 만듦
- 데이터 백만개 막 넣고 하셨음 -> 서버 터질수도 있음
- 호눅스님의 bulk insert 하셨던 거에서 영감을 받아서 썼음
- 하버사인 공식 맞나요? 직접 구현하신건가요?
- 검색해서 도움을 좀 받았습니다
- 마감시간은 서버에 1초마다 동기화를 한건가요?
- SSE 라고 하는 개념
- 서버에서 클라이언트로 보낼수있는 통신
- 웹소켓보다 가벼운 기술이라고 하여 도입
- 웹소켓은 ws 프로토콜만 사용가능, SSE는 http로도 가능
- 웹소켓 쓰는것도 나쁘지 않다고 생각합니다
- SSE는 단방향 통신이라...
- 프로젝트 내에서 인덴트가 통일이 안된것 같은데 prettier 이나 eslint는 사용하시나요??
- prettier 사용하고 있습니다
- 탭으로 하는게 구분감이 좋은것 같아서 사용합니다
- soft tab vs hard tab 키워드 감사합니다
- 100만개... 갖고싶다... 저 녀석...
- 쿼리 최적화 엑셀로 남겨놓은 거 좋은 것 같아요 👍