1. 프로젝트

1) 프로젝트 소개

• 🌞weather github 저장소 바로가기

"weather" 는 react, redux, redux-middleware(thunk, saga)를 사용해 kakao local REST API와 공공 데이터 포털에서 제공받은 데이터를 통해 사용자에게 사용자의 현재 위치에 따른 국내의 날씨 정보를 알려주는 날씨 정보 사이트로 사용자는 현재의 자신의 위치에 따른 현 시점의 날씨, 앞으로 3일 이내의 시간별 날씨, 일주일간의 전국 날씨, 일출 일몰 시각을 제공받을 수 있다. weather의 웹디자인은 네이버 날씨를 참고했다.

weather project 실행

2) 프로젝트 목적

weather 프로젝트는 다음과 같은 시도들을 해보기 위해 시작된 프로젝트이다.

• CORS 정책을 준수하며 외부에서 제공하는 데이터를 REST FUL하게 받아오기

• redux-toolkit , redux-middleware인 thunk 와 saga 의 차이점을 경험해보고 각각의 장단점과 언제 사용해야하는지 생각해보기

• Github의 Actions 와 Secrets를 사용해 API key 를 깃헙에 올리지 않고도 사용할 수 있게 하기

• table,th,td,tr의 태그 사용에 익숙해지기

• 시간별 날씨를 그래프로 표현해보기

2.배운 점.느낀점

1) 외부 데이터 분석

☁️weather 프로젝트에서 사용된 API

• 기상청 단기예보 : 초단기 실황, 초단기 예보, 단기 예보
• 기상정 중기예보 :중기 육상 예보, 중기 기온 예보
• 에어코리아 대기오염정보 : 시도별 실시간 측정정보
• 한국 천문연구원 일출일몰시각정보
• kakao local REST API : 위치의 행정구역 정보

rootState에 필요한 데이터의 형식을 내가 직접 만들었던 때와는 달리 이번 weather 프로젝트는 타인이 만든 여러 외부 데이터들을 사용하게 되었다.
내가 데이터를 만들때 와는 달리 API 마다 다른 데이터 요청 조건(ex: 예시1)과 데이터 형식을 분석하고 내가 원하는 형식으로 데이터를 재가공하는 과정을 거쳐야했다.

예시1) baseDate로 쓰이지만, API마다 다른 baseDate가 필요했음

//changeBaseDate : Date를 string type 의 "yyyymmdd" 형태로 바꾸어주는 함수 

// 데이터 조회 시각에 따라 baseDate의 기준을 오늘로 할 지 어제로 할 지가 달라짐
  const baseDate_today =changeBaseDate(today);
  const baseDate_yesterday =getYesterDay(date);
// 하늘상태를 조회할 때 필요한 baseDate
  const baseDate_skyCode = minutes < 30 && hours === 0 ? 
                          baseDate_yesterday
                          :
                          baseDate_today ;
//단기예보 조회에 필요한 baseDate
  const baseDate_svf = hours < 2 ? baseDate_yesterday :baseDate_today;
  

navigator를 이용한 사용자의 위도, 경도값이 기상청에서 제공한 위치 데이터 자료와 일치하지 않아서 카카오 API를 활용해 사용자의 위치값에 따른 행정구역명을 찾아내고 이를 통해 날씨 데이터를 요청할때 필요한 값들을 구해야했다.

2)API Key 보안

프로젝트를 깃헙에 배포하되 보안을 위해 API Key는 깃헙에 배포하지 않으면서도 배포된 프로젝트에서 API에 접근할 수 있도록 해야 했다.

그래서 선택한 방법은 개발 환경에서는 .env에 환경변수로 API Key를 등록하고 배포환경에서는 Github Secrets에서 작성한 key를 Github Actions를 통해 배포 환경에서도 사용할 수 있도록 하는 방법이였다.

👩‍💻"React(CRA)개발 시 API Key설정보안" 에 대한 블로그 글 보러가기

3) Redux Toolkit,Redux Thunk, Redux-Saga

이번 프로젝트를 통해 Redux Toolkit,Thunk와 Saga를 사용해보고 이 셋의 장단점과 차이점을 알아보고 싶었다.
코드의 결과문에서는 체감적을 느껴지는 차이는 없었다.

• redux-toolkit, redux-thunk ,redux-saga를 사용한 함수

	position	weather
tooklit(createAsycnThunk 사용)	toolkitPosition	toolkitWeather
thunk	getPositionThunk	getWeatherThunk
saga	getPositionSaga, positionSaga	getWeatherSaga, weatherSaga

그러나 action의 type에 있어서는 차이가 있었다.
action type을 다음의 4가지로 설정해서 작업을 진행했다.

• reset: 상태 초기화
• request: 데이터 요청
• success: 데이터 성공적으로 받음
• failur: 데이터 요청 실패

Redux Middleware는 createSlice의 리듀서에서 정한 것들을 활용할 수 있지만 createAsynThunk 는 비동기 작업에 따라 "pending, fulfilled, rejected"의 액션타입을 자동으로 생성하기때문에 일반적인 리듀서와는 다르게 처리해주어야해서 extraReducers 을 사용해 리듀서를 처리해주어야한다.

weather reducer

export const weatherSlice =createSlice({
  name:"weather",
  initialState,
  //thunk, saga
  reducers :{
    reset :(state)=>({
      ...noneState_weather
    }),
    request :(state , action:PayloadAction<PositionSuccessData>)=>({
        ...noneState_weather,
        state:"pending"
      }),
    success :(state, action:PayloadAction<WeatherState>) =>({
      ...action.payload,
      state:"success"
    }),
    failure : (state, action:PayloadAction< Error>)=>({
      ...noneState_weather,
      state:"failure",
      error:action.payload
    })
  },
  //toolkitWeather 
  extraReducers(builder) {
    builder
    .addCase( toolkitWeather.pending , (state, action)=>{
      return {
        ...noneState_weather,
        state:"pending"
      }
    })
    .addCase(toolkitWeather.fulfilled , (state, action)=>{
      return{
        ...action.payload
      }
    })
    .addCase(toolkitWeather.rejected, (state, action)=>{
      return {
        ...noneState_weather,
        state:"failure",
        error:action.error as Error
      }
    })
  }
});

그리고 같은 weahterAction 이라는 action을 사용하지만, dispatch의 타입을 셋 다 다르게 해줘야했다.

dispatch type

//redux-thunk
const weatherThunkDispatch =useDispatch<ThunkDispatch<WeatherState, unknown,WeatherAction>>();

//redux-saga
  const dispatch =useDispatch();

//redux-toolkit
  const toolkitDispatch =useDispatch<ThunkDispatch<PositionState|WeatherState, CurrentPosition|PositionSuccessData, AnyAction>>();

action dispatch

if(startThunk.current){
       // redux-thunk 이용  
  weatherThunkDispatch(getWeatherThunk(positionSuccessDate))
        startThunk.current = false; 
      }else if(startSaga.current){
        // redux-saga 이용  
       dispatch(weatherActions.request(positionSuccessDate));
        startSaga.current =false;
      }else{
         // redux-toolkit 이용
        startToolkit.current =false;
        toolkitDispatch(toolkitWeather(positionSuccessDate))
      }

그리고 이번 프로젝트내에서 코드 실행 결과에 있어서 별다른 차이점이 없었지만 Redux Toolkit은 Redux의 편한 사용을 위해 만들어졌고, Redux Middleware는 비동기 작업을 관리하는 것을 목적을 하기 때문에 보다 복잡한 비동기 작업에 있어서는 Redux Middleware가 더 적합하다.

🌟정리

• 코드 실행 결과에서는 큰 차이점을 느끼지 못했다.
• reducer 코드를 만들때 Toolkit을 활용한 경우를 대비해 extraReducers를 만들어주어햐 했다.
• dispatch의 타입을 다르게 설정해야 했다.
• 보다 복잡한 비동기 작업에서는 Redux Middleware가 더 적합하다.

👩‍💻 Redux Thunk 와 Redux Saga를 비교한 블로그 글 보러가기

4) Reducer 간편하게 작성하기

:Redux Toolkit 과 typesafe-actions

action와 reducer를 간편하게 작성할 수 있는 도구들로 typesafe-actions와 Redux Toolkit등이 있다. 프로젝트를 하면서 둘 다 사용해봤는데, Redux Toolkit만으로도 충분해서 별도로 설치해야하는 typesafe-actions 을 사용하지 않기도 했다.

🖱️ redux-toolkit 사이트 바로가기

5) Chart.js사용

📈 Chart.js 사이트 바로가기

📈 Chart.js 를 사용해 만든 기온 그래프

📈 Chart.js 로 만든 그래프 코드

시간별 기온에 대한 그래프를 Chart.js를 사용해 만들었다.
처음 사용하는 라이브러리였다.
최저 기온과 최대 기온을 기준으로 한 y축, 시간별 x축의 폭 등 생각보다 잘 만들었다.

하지만 아쉬움도 있었다.Chart.js는 canvas에 그래프 이미지를 그리는 방식이라 weather 프로젝트처럼 x축과 y축의 길이가 차이가 많이 나면 그래프 이미지가 늘어나서 그래프 선과 그래프의 수치를 나타내는 부분이 깨지는 문제점이 있었다.

그래서 기온을 나타내는 수치의 경우,Chart.js 를 이용하지 않고 각 시간대별 온도에 따르 y값을 계산하는 방식으로 따로 element를 생성해서 표현했다.

6) 차단됨(mixed-content) error

: Node.js 공부 필요성을 느낌

개발환경에서는 괜찮았지만 배포 환경에서는 API에서 데이터를 받아올 때 차단됨(mixed-content) 오류가 발생했다.

A. mixed content(혼합 콘텐츠)?

mixed content(혼합 콘텐츠)는 HTTP 콘텐츠와 HTTPS 콘텐츠가 함께 로드되는 것으로 크롬과 파이어폭스등 웹브라우저에서 안전상의 이유로 https 페이지에서 HTTPS가 아닌 HTTP 로 받아오는 리소스를 차단하고 있다.

B. mixed content 에러 원인

weather 페이지에서 mixed-content 에러가 발생한 이유는 weather 페이지는 HTTPS 프로토콜을 사용하는데 일출일몰에 대한 데이터와 미세먼지,초미세먼지에 대한 데이터는 http에서 제공하는 것이기 때문이였다.

C. mixed-content 에러 해결 방법

① API를 HTTP가 아닌 HTTPS 프로토콜을 사용하도록 API 제공자가 수정
② 백엔드에서 API 데이터를 받아와 프론트엔드에 넘기기
③ META 태그를 헤더에 추가하여, http 콘텐츠를 자동으로 https로 변환하여 로딩하기

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> 

C-①은 API 제공자가 해야하는 방법으로 내가 할 수 없고, C-③을 시도했지만 오류가 해결되지는 않았다. 그래서 C-②의 방법으로 오류를 해결해야한다는 결론을 내렸고 Node.js를 공부해야 하는 필요성을 더 느끼게 되었다.

D. Node.js를 통해 mixed-content 오류 해결하기

mixed-content를 문제를 해결하기위해 Node.js 와 express 모듈를 이용해 node 서버를 만들고 서버에서 외부 api에 요청을 보내 날씨 정보에 필요한 데이터를 받아온 후 이를 프론트에 넘겨주는 방식을 mixed-content 오류를 해결했다.

🖱️"Node.js를 통해 mixed-content 오류 해결" 에 대한 블로그 글 보러가기

7) Node.js 공부

Node.js를 공부하면서 정리한 블로그 포스트

• 👩‍💻"React + Node(express)연동"에 대한 글 보러가기

• 👩‍💻"React와 Node.js 연동 시 404 error"에 대한 글 보러가기

• 👩‍💻"Node.js를 통해 mixed-content 오류 해결"에 대한 블로그 글 보러가기

6)의 mixed-content 오류를 만나면서 언젠가 하겠지라면 생각한 Node.js에 대한 공부를 시작했다. Node.js를 공부하면서 서버에서 React 프로젝트를 어떻게 열 수 있을 것인지, 서버와 프론트엔트가 데이터를 어떻게 주고 받을 수 있을지, 그 과정에서 비동기를 어떻게 해결할 것인지를 중점적으로 봤다.

그리고 Node서버를 통해 React를 열였을 때, css의 파일의 속성들의 순서가 변경되는 오류가 발생했었다. 이를 통해 css 속성을 작성할 때 해당 우선순위가 적용되어야하는 경우라면 뒤에 코드를 추가하는 것보다 하나의 코드를 보다 정확하게 설정하는 게 좋겠다는 경험도 할 수 있었다.

오류가 난 scss 코드

변경 전

	.bar{
   //...
   border : 7px solid $bar_bg;
   border-bottom:7px solid $bar_percent_bg;
   border-right: 7px solid $bar_percent_bg;
   
   }

border-bottom이 border 보다 우선 적용되도록 코드를 작성했는데 Node 서버를 실행하면 border-bottom 후에 border가 나와서 border-bottom이 아닌 border가 우선 실행되는 오류가 발생했다.

그래서 일몰 상황을 표현하는 그래프가 중간에 끊기는 문제가 생겼다.

변경 후

.bar{
      border-style:solid;
     border-width: 7px;
     border-color: $bar_bg $bar_percent_bg $bar_percent_bg $bar_bg;
     }

3. 아쉬운 점

아래의 사진처럼, 원래 계획한 버전에는 전국의 날씨를 일주일별로 알려주는 기능이 있었지만 배포된 최종 버전에는 해당 기능을 삭제했다.

이유는 ETIMEDOUT 에러 때문이였다.
ETIMEDOUT은 연결 시간 초과오류로, 로컬 환경에서는 전국 날씨에 대한 데이터를 받아올 수 있었지만, cloudeType으로 Node와 React를 배포한 배포사이트에서는 ETIMEDOUT 오류가 나타났다.

해당 에러의 원인은 다음과 같다.

1. 서버의 정보를 잘못 기입
2. 서버에 접근할 권한이 없음
3. 요청 시간이 부족

공공 API를 받아오는 것에는 문제가 없었고, 전국 시도별 일주일 데이터를 공공API에서 제공해주는게 아니라 여러 데이터들(하늘상태,초단기예보,단기예보,중기예보등등)을 시도별로 일주일치 받아와서 받아오다보니, 데이터를 받는 시간이 특정 시간을 넘다보니 "ETIMEDOUT" 오류가 생긴것 같다.

다른 배포 사이트를 이용할 수 도 있지만, 로컬 환경에서도 전국 날씨를 받아오는 작업으로 인해 로딩 시간이 5분정도 걸려서 사용자 경험측면에서 좋지 못하다고 생각해서 전국 날씨를 알려주는 기능은 제외하기도 했다.

4. 마무리

twitter와 notion을 클론 코딩하는 프로젝트들을 혼자 처음부터 모든 것을 부딪치면서 하다보니 몇달 씩 시간이 걸렸고 언제 이걸 끝낼 수 있을까하며 계속되는 오류와 수정에 힘들었다. 이제 언어를 막 배운 병아리 수준에서 너무 호기롭게 거대한 프로젝트를 괜히 시작한 거 아닐까하는 생각도 들었는데 weather 프로젝트를 하면서 그래도 앞선 프로젝트를 하면서 배우고 체득한 것들이 어느정도는 내것이 되었다는 것을 확인할 수 있는 시간이였다.

앞선 두 프로젝트에 비해서 프로젝트의 복잡도나 크기가 크지는 않지만, 그동안 궁금했고 해결하고 싶었던 외부 API 이용, Redux Middleware와 Redux Toolkit사용, Node 서버와 React 연동하기 등을 해봤고 여러 오류들을 수정하고 "네이버 날씨"에서 사용한 웹디자인과 class, css 요소들을 구경하면서 새로운 것들을 알아가기도 한 뿌듯한 경험이였다.