프론트엔드의 꽃, 리액트 - 마지막주차 개발일지( middleware, AWS )

GD프로젝트 리액트 기초

프론트엔드의 꽃, 리액트 마지막 주차도 드디어 끝이 났다.

이번 5주 차에 있었던 일을 바로 기술해보겠다.

 

 

목차

1. 새롭게 배운 내용

2. 결과물

3. 5주동안 배운 내용 간단 요약

4. 후기

 

 

---

1. 새롭게 배운 내용

---

 

1 - 1 middleware

미들웨어는 단어 뜻 그대로 소프트웨어와 운영체제 가운데에서 중재하는 역할을 한다.

 

미들웨어 종류는 여러 가지인데

우리가 5주 차에 배웠던 미들웨어는 firebase내에 있는 firestore와 redux 데이터를 연결하는

미들웨어인 redux-thunk를 배웠다.

 

redux-thunk는 액션과 리듀서 가운데에서 중재하는 역할을 한다.

더 자세히 말하자면 사용자가 이벤트를 일으켜 액션이 일어나고 -> 

미들웨어가 실행 ->

리듀서 로직 실행

이렇게 일어난다.

 

만약 firebase나 다른 DB를 이용하지 않고 단순히 프런트에서 데이터를 저장하면

(즉 데이터를 jsx, js 파일 내에서 저장한다면)

미들웨어 없이도 정상 동작이 가능하다.

 

그런데 firebase같이 외부에 있는 DB에 사용자가 입력한 데이터를 저장하려면 

미들웨어가 필요한 것이다.

 

 

그럼 redux-thunk는 어떻게 생겼을지 궁금할 것이다.

redux-thunk는 미들웨어 그 이상도 이하도 아니다.

ㅋ

우리가 redux를 이용하기 위해 액션과 액션 크리에이터를 만들면

객체를 반환하다는 것을 알 것이다.

 

// action
const LISTLOAD   = 'list/LOAD';

// action creator
export const loadList = (list) => {
    return { type: LISTLOAD, list };		//객체 반환
}

 

redux-thunk는 객체 대신 함수를 생성하는 액션 생성 함수를 작성할 수 있게 해 준다.

왜 액션 생성함수면은 미들웨어 처리과정을 더욱 세밀하게 제어하기 위해서다.

 

 

 

// action
const LISTLOAD   = 'list/LOAD';

// action creator
export const loadList = (list) => {
    return { type: LISTLOAD, list };		//객체 반환
}

// action create function
export const loadListFB = () => {     // 파이어베이스 통신하기 위한 함수
    return function (dispatch) {        // 이 함수의 두번째 인자는 모듈안에 있는 스테이트 값을 가지고 오는 인자이다
        list_DB.get().then((docs) => {
            let list_data = [];
            docs.forEach((doc) => {
                if(doc.exists){
                    list_data = [...list_data, {id: doc.id, ...doc.data()}];
                }
            })
            dispatch(loadList(List_data));
        })
    }
}

// reducer
export default function reducer(state = initialState, action = {}) {
  switch (action.type) {
	case "list/LOAD": {
        return {list: action.list};
    }
    default: return state;
  }
}

 

 

이렇게 액션과 리듀서 사이에 실행되는 로직으로서 외부에서 데이터를 받고 그것을 리듀서가 처리한 후 

우리가 사용하는 컴포넌트와 데이터를 송수신할 수 있다는 것이다.

 

그렇다. redux-thunk(미들웨어)는 DB 또는 다른 소프트웨어 같은 외부와 

우리가 사용하는 컴포넌트와의 소통의 매개체이다.

 

 

 

1 - 2 AWS

 

5주 차에는 AWS의 S3(Simple Storeage Service)를 이용하여 앱을 배포하였다.

도메인은 가비아에서 직접 샀다.

 

 

AWS S3 정적 웹 사이트 호스팅 방법[클릭]

 

처음 호스팅하고 도메인 설정하는 것이 약간 귀찮을 뿐이지

한 번 설정하면 업로드 파일만 변경해주면

도메인에 쉽게 변경사항을 적용할 수 있다.

 

 

 

---

2. 결과물

---

 

 

 

 

5주 차 완성물 보러 가기 [클릭]

 

코드 보러 가기 [클릭]

 

웹을 만드는 것이 너무 좋아서 과제에 요구한 것보다

더 열심히 한 것 같다.

또한 친구들에게 보여주니

 

 

 

이런 거나 입력하고 앉아있다

 

정말 좋은 친구들이다.

 

 

 

---

3. 5주동안 배운 내용 간단 요약

---

 

1. 컴포넌트 생명주기

 

컴포넌트가 생성이 되면 construcotr -> rendering -> state,ref -> componentDidMount

-> (setState/props값이 수정되면) -> ShouldComponentUpdate -> reRendering

컴포넌트가 소멸이 될 시점 -> componentWillUpmount -> 소멸

 

 

2. 컴포넌트의 데이터 저장 및 송수신

 

2 - 1 데이터 저장

 

하나의 변수가 컴포넌트에 영향이 가지 않으면 일반 변수 (ex : let a;)

영향이 가야한다면 state (ex : const [a, setA] = useState(0);)

 

2 - 2 데이터 송수신

 

자식 컴포넌트에게 전달한다면 props

부모 또는 외부 컴포넌트에게 전달해야 한다면 redux

외부 소프트웨어 및 DB에게 전달해야한다면  redux-thunk

 

2 - 3 redux

 

사용자의 행동을 정의하는 action

그 행동에 따라 필요한 데이터를 정의하는 action creator

데이터를 받고 실행돼야 하는 로직을 정의하는 reducer

 

 

 

 

 

 

---

4. 후기

---

수업이 5주 차로 되어있었지만 사실 2주일 동안 한 것이다.

처음엔 2주일이면 너무 짧은 것이 아닌가 생각했는데

저번 주에 정처기 실기 공부한 시간을 빼면 충분히 가능할 것 같다고 생각한다.

 

5주 차 분량의 수업을 들어보니

웹을 어떻게 설계해야 할지 어느 정도 감이 잡힌다.

5주 차 동안 진행된 과제를 통해 느낀 점도 많았다.

 

1. 프론트와 백 중에 백부터 구현하는 것이 낫다.

 

프론트부터 구현하면 임시 가짜 데이터를 넣어서 뷰가 어떤 형태로 나오는지 구현해야 되는데

그러다 백이 늦게 구현하면 프론트는 다시 코드를 짜야한다.

똑같은 일은 2번 하게 되는 것이다.

 

2. 수시로 변경되는 데이터들은 프론트가 아닌 DB에서 처리하는 것이 낫다.

 

프론트에서 처리하면 데이터가 변경될 때마다 build 해야 되고 배포도 다시 하는데

DB에서 처리하면 DB에 있는 내용만 수정하면 된다.

 

3. DB에서 받아온 데이터는 웬만하면 redux store에 저장해야 한다.

그리고 유저가 선택한 부분만 받아와야한다. 

 

똑같은 데이터라도 여러번 받아오면 안된다.

그래야 웹 성능이 조금이라도 올라간다.

 

4. 사용자는 클릭 한 번이라도 귀찮아한다.

 

그래서 UI를 짜고 설계할 때 최대한 사용자를 불편하게 만들면 안 된다.

 

그것이 개발자의 덕목이니까

 

이번 주부터는 리액트 심화반 수업이 진행되는데 이번에는 어떤 것을 배우고 만들지 기대된다.