프로젝트 수행 결과

전체 프로젝트 구조

• components - base(재사용 가능, 도메인 특성이 담기지 않은) - domain(도메인의 특성이 담긴, ex_네비게이션, base를 확장해서 도메인 특성을 담은 경우)

• contexts - user, navigation, post, weather

• hooks

• pages

• routes - PrivateRoute, PreventedRoute

• styles - theme, reset, font

• utils - api 통신 관련, 상수, 함수

• styled component 작성 규칙
• style.js 파일로 분리하기
• Card 폴더 - index.tsx
- style.js

상태 관리(context api)

• 서비스 규모가 크지 않기 때문에 recoil, redux등의 외부 라이브러리의 사용은 자제하기로 하였다.

• 따라서 react 라이브러리에 내장되어있는 context Api를 사용하기로 합의를 하였다.

• 또한 전역적으로 꼭 관리가 필요한 상태 혹은 props drilling이 일어나는 경우에서만 context Api를 사용하였다.

• 따라서 본 서비스에서는 User에 대한 정보만 context에 보관하였다.

공통 요소 관리

• axios interceptors의 사용
• 네트워크 통신을 통해 오는 값의 타입을 알 수 없다.
• 하지만 모든 api에 대해서는 예외처리를 해주어야 하며, 우리는 우리의 코드가 예측가능하기를 원했다.
• 따라서 에러 상태에 대한 정의를 interceptor에서 해주었다.
• 따라서 우리는 우리가 정의한 타입에 맞게 모든 오류를 일차적으로 분류를 할 수 있었다.
• 다음으로 실제 api를 사용하는 곳에서는 각 페이지별 상황에 맞게 에러 핸들링을 해주었다.
• <사용하는곳>



• interceptor에서의 타입



• 우리는 모든 api에서 인증이 필요하였다. 따라서 모든 header에 Authorization을 넣어주어야 했다.
• 따라서 이를 막기 위해 interceptor와 instance를 통해 코드의 중복을 최소화하고자 하였다

• 이를 위해 여러 방법이 있지만 우리는 api를 정의하는 부분에서 Generic으로 지정해주었다.

• 이렇게 하지 않는다면 사용할 때 마다 as를 통해 타입을 지정해주거나 any타입으로 데이터가 받아지기 떄문에 좋지 않은 방법이라고 생각하였다.
이에 따라 모든 경우에 타입의 추론이 잘 되었고 중복코드 또한 많이 줄었다고 생각한다.

• ThemeProvider로 공통 스타일 정의
• 프로젝트의 전체적인 스타일을 맞추기 위하여 글자 색상, 글자 크기, 요소 사이의 간격 등을 ThemeProvider에 미리 정의하여 추후에 변경사항 발생시 유지 보수가 쉽도록 하였습니다.

빌드

• 서비스를 개발하면서 빌드에 신경을 쓰지 말고 개발에 집중하기로 하였다.

• 그러기 위해는 빌드프로세스에 대한 자동화가 필요했다.

• Jenkins, circleCi 등 다양한 도구가 존재하였지만, 우리는 github Actions를 사용하고자 하였다. 그 이유로는
• 형상관리도구로 git과 github을 활용하였다.
• 따라서 다른 도구들은 별도의 계정이 필요하지만 github Actions을 활용한다면 별도의 계정이 필요하지 않았다.
• 우리는 main 브랜치에 push가 올라갈 때만 build 자동화를 하면 된다.
• 즉 모든 프로세스에서 ci/cd가 필요한것이 아니었기 때문에 workflow를 통해 간단하게 사용할 수 있는 github Actions를 사용하기로 하였다.

• test와 main develop의 분리
• 개발을 하면서 반드시 지속적인 테스트가 필요하다.
• 하지만 실제로 사람들이 사용하는 서비스에서 직접적인 테스트 코드를 올린다는것은 치명적인 에러를 유발시킬 뿐만 아니라 사용자의 경험 또한 떨어트린다고 생각하였다.
• 따라서 코드에 대한 기기별 대응을 직접 확인하고 싶다면, test branch에 push를 하도록 하였다.
• 즉, 우리는 test endpoint와 develop endpoint 두개를 통해 지속적인 기기별 테스트를 진행하며 테스트가 다 완료되고 난 후 main branch에 push를 하였다.
• main endpoint - https://d3hatotnvqhqmx.cloudfront.net/
• test endpoint - https://d2jeyu0p1z8lkj.cloudfront.net/login

문서화

• 깃헙 위키
• 깃헙 위키에 프로젝트를 진행하면서 했던 고민과 마주했던 문제 기록

서비스 화면별 주요기능(내일 저녁에 캡쳐해서 화면 이미지 붙일 예정)

• 라우터 설정(유저의 로그인 상태에 따라 페이지 접근 가능 여부를 관리)
• 로그인 유저(회원) 접근 가능 페이지
• 홈
• 게시물 열람
• 게시물 엿보기
• 게시물 작성
• 마이페이지
• 로그인 하지 않은 유저(비회원) 접근 가능 페이지
• 로그인
• 유저 인증

• 로그인
• 유저의 개인정보 관리에 드는 비용을 줄이기 위하여 로그인은 카카오 로그인 api활용

• 홈
• 지도 api는 react-map-gl을 이용하여 구현
• geolocate를 사용하여 유저의 현재 위치에 맞는 지도가 뜨도록 구현
• 서버에서 유저가 열람 권한이 있는 게시물을 받아와서 게시물에 저장된 위치 정보에 따라 지도 위에 마커가 표시되도록 구현
• 게시물의 열람 가능여부에 따라 마커의 색상을 다르게 구현
• 유저가 처음 홈 화면에 접속 시 오늘 열람 가능한 게시물이 있다면 알림을 띄워 해당 게시물로 이동할지 여부를 확인함, 유저의 승인시 해당 게시물의 엿보기 페이지로 이동하도록 구현

• 엿보기
• 유저가 마커를 클릭하면 해당 게시물의 간략한 정보를 보여주도록 구현
• 게시물의 열람 가능 여부, 권한에 따라 버튼 변경

• 게시물 생성
• react-map-gl, geolocate를 사용하여 유저가 원하는 위치에 게시물을 생성하도록 구현
• 로컬스토리지를 활용하여 유저가 게시물 생성중에 이탈하더라도 작성중인 데이터가 날라가지 않도록 구현
• 유저를 검색해서 해당 게시물에 열람 권한을 부여하도록 구현

• 게시물 열람
• 작성자가 지정한 날짜가 되면 게시물을 볼 수 있도록 구현
• 최초 개봉자의 경우 로띠를 활용한 효과 구현

• 마이페이지
• 내 게시물과 공유받은 게시물을 나눠서 볼 수 있도록 구현
• 게시물을 열린 것과 닫힌 것을 나눠서 볼 수 있도록 구현