[3주차 피어 세션: 01. 이벤트 수집기 A & B & C 🌿]
작성자: N.킴 , C.조(Cat)
- A : 유선규, 이유택, 유선규
- B : 김민지, 임지영, 조정혜
- C : 김도균, 박지홍, 이상경
- 쿼리로 간단하게 결과 돌려주는 방식으로 했음
- input 할 때마다 요청 ? -> 그렇게 할 것 같다
- 자동완성 : 쓰로틀링 참고
- 차트 같은 경우는 실시간으로 하기 위해 서버사이드로 생각
- 나머지는 빌드 시 스테틱으로 불러오지 않을까
- 업데이트가 많이 발생하는 것들은 서버사이드가 좋지 않을까
- 페이지별로 구분하는게 어떨까 하는 생각을 했음
- 공통적으로 나오는 부분 reduce, hook ?
- A팀의 Emitter 좋은 아이디어인 것 같다
- Emitter에서 이벤트 발생 -> Collector에서 로그쏘기
- 이벤트를 어디까지 수집할지
- 멘토님
- 모든 이벤트를 수집하지만 자율적으로 기준을 정해보는게 좋을 것 같다
- top-down 방식으로 수집
- 유저의 개인적인 인터렉션을 중심으로 수집할 예정
- 멘토님
- 유저나 페이지 등 기준을 잡고 나누는 방법
- 클라이언트에서 서버에 어떻게 보내는지
- 백엔드 api 요청 시 인증이 필요한 부분에서는 미들웨어 활용
- A팀
- interface 작성 힘들었음
- B팀
- atomic design을 적용하는 것 자체가 어려웠음
- 조금씩 다른 style 적용
- 컴포넌트를 어떤 단계로 나눌 것인지
- atomic design을 적용하는 것 자체가 어려웠음
- C팀
- 소셜로그인할 때 토큰 처리하는 부분이 어려웠음
- 이벤트를 어떻게 보낼지
- 데이터 가져오는 부분들
- 따로 테이블을 두지 않고 랜덤으로 아무거나 가져올 생각
- useSWR 사용하면 특정 시간마다 변경되는 데이터를 받아올 수 있음
- useSWR 사용은 어떨까? (주기적 사용)
- redux 써보자 정도로만 생각하고 있음
- 상태관리가 필요한 부분이 많지 않은 것 같다
- Wrapping Component
- 개발자가 정하는 건 아닌 것 같다.
- 필요할 때 사용할 수 있도록 끌어쓸 수 있는(재사용 가능한) 형태로 구현하기
- 재생 관련 이벤트가 중요한 것 같다.
- 대부분 사용, 사용하지 않는 팀도 있음
- 난이도가 쉬워지는 것 같아서 우선 사용하지 않을듯
- 생각보다 커스텀이 자유롭지 않음
- 직접 CSS 하는 것이 재밌따
- 쿠키에 담고, 쿠키 그대로 전달한다.
- 보안 문제 찾아보기
- _app.js 쓰면 자동으로 해주는게 사라진다? 알아보기
- getInitialProps 쓰면 getStaticProps 명시해야 함: 아니면 getServerSideProps가 default?
- styled.audio 활용
- slider 활용
- 추천은 DB에서 랜덤으로 가져올듯
- 현업에서는 테이블을 따로 두지 않고, 적절한 로직에 따라서 조회