PPT 발표 자료

https://docs.google.com/presentation/d/1wlfl2o4_DG0koQbvEOogVaAnWFcAe6mDZx_8wMp7-BM/edit?usp=sharing

FrontEnd

기술적 의사결정 (1분 30초)

• react-query 선정 이유

  • 클라이언트 쪽 데이터 관리엔 용이하나, 서버 쪽 데이터 관리에 불편한 점이 많다.

  • 서버에서 비동기적으로 받아오는 데이터를 처리하기 위해 redux-thunk 등을 사용해 비동기 처리 수행 후, 데이터를 redux store에 저장하여 각 컴포넌트에서 사용했다.

  • 비동기 처리 수행 중 isLoading 등의 로딩 상태를 직접 선언하고 처리해야 한다.

  • redux-toolkit의 등장으로 redux boilerplate 양이 줄어들었음에도, 여전히 비동기 처리 시 반복되는 boilerplate 코드량이 많았다.

  • API 통신을 위한 규격화된 방식의 부재 : Redux는 API 통신 및 비동기 상태 관리 목적 라이브러리가 아니기 때문에 비동기 데이터를 관리하기 위한 코드를 개발자가 모두 결정하고 구현해야 했다. 즉, redux는 범용적으로 사용하는 전역 상태 관리 라이브러리였기 때문에 규격화된 비동기 데이터 관리 방식이 없어 협업이 복잡해질수록 데이터 관리가 까다로웠다.

    EX. API 로딩 여부Boolean을 사용해서 관리IDLE | LOADING | SUCCESS | ERROR 등 상태를 세분화하여 관리

• recoil 선정 이유

  • 서버 데이터 관리는 리액트쿼리를 사용하기 때문에 간단하게 전역상태관리할 라이브러리가 필요했음
  • 리코일은 러닝커브가 낮고 atom, selector로 어느정도 간단하게 구현 가능
  • 리액트쿼리를 쓰면서 리덕스를 쓰는 건 너무 비효율적
  • context api 단점 : context api는 상태값을 변경할 경우 provider로 감싼 자식 컴포넌트들이 리렌더링되는 문제가 발생함. provider 내부의 값이 거의 변하지 않는 상황에서 props drilling에 유리
  • mobX보다 recoil 사용이 더 간단함 : 서버데이터는 리액트쿼리로 관리하고 있기 때문에 정말 간단한 전역상태관리만 필요

추후 개발 및 기술적인 도전 계획 (1분 30초)

• 실시간 알림
• 애플로그인 (과금)
• 팔로우, 팔로워 (알림, 수락, 거절, 끊기 등)
• 모바일 최적화 (기기별 테스트)
• 습관 삭제
• pwa 적용
• 월간 달력
• 주간 달력
• 데이터 캐싱 처리