[패스트 캠퍼스] MegaByte School 프론트엔드 3기 회고 - 23주차

당근 먹는 쿼카·2023년 2월 17일
MegabyteSchool개발자취업부트캠프국비지원교육내일배움카드메가바이트스쿨패스트캠퍼스
0

회고록

목록 보기
24/38
post-thumbnail

안녕하세요, 패스트 캠퍼스 메가바이트 스쿨 프론트 엔드 3기 수료 중인 김당퀔입니다! 이번 3기 수료 기간은 9월 13일부터 4월 14일까지 총 7개월 과정입니다. 7개월 동안 매주 주말 회고록을 작성해 보려고 합니다.

블로그 제출 기한으로 인해서 지난 금요일부터 해당 주 목요일까지의 사이클로 작성됩니다.

1. 요일별 공부 기록

❤ 2월 10일 금요일

  1. Field-Passer
  • React Query 공부해 보기
  • API 연결
  • TS 설정
  1. 리액트 스터디
  2. 안재원 강사님 수업
  • JWT = Json Web Token
    마지막 수업이라 꽤나 아쉬웠던...!

🧡 2월 11일 토요일

  1. 백준
  1. Field-Passer
  • TS 설치 및 설정
  • API 연결 코드 작성

💛 2월 12일 일요일

  1. 리액트 퀵 스타트

axios를 이용한 HTTP 통신

axios?

HTTP 기반 통신을 지원하는 가장 많이 사용되는 자바스크립트 라이브러리.

axios vs fetch

구분axiosfetch
모듈 설치npm install --save axios브라우저 내장 API
Promise API사용사용
timeout 기능지원, tiemout 시간 내에 응답이 오지 않으면 중단시킬 수 있음지원하지 않음
JSON 자동 변환지원, Content-type 정보를 이용해 자동으로 객체로 변환지원하지 않음

RESTful API 테스트 서버

크로스 오리진

크로스 오리진 (cross origin) 문제란 브라우저는 자신의 오리진과 다른 오리진의 API 서버와 통신할 때 문제가 발생한다 는 개념. 크로스 오리진 문제를 발생시킴으로써 잠재적인 위험을 가진 문서의 로딩을 제한해 브라우저 공격의 가능성을 줄일 수 있다. 웹 브라우저에 내장된 SOP(Same Origin Policy: 동일 근원 정책)라는 보안 정책 때문에 발생.

CORS

크로스 오리진의 브라우저가 백엔드 API 서버로 요청했을 때 서버에서 Access-Control-Allow-Origin HTTP 헤더로 브라우저의 오리진을 응답하여 브라우저가 통신 및 데이터 로딩을 할 수 있도록 허용하는 방법.

  • 브라우저는 프론트 서버에서 HTML 문서를 받아와 자신의 오리진을 설정.
  • 자바스크립트 코드로 백엔드 API 서버에 요청. 이때 자신의 오리진을 Origin HTTP 헤어데 추가.
  • 백엔드 API 서버는 전송된 Origin 헤더를 읽어내어 등록된 리스트에 일치하는 것이 있는지 확인. (이 단계는 선택적)
  • 백엔드 API 서버는 Access-Control-Allow-Origin 응답 헤더를 추가하고, * 또는 브라우저의 오리진을 값으로 지정하여 응답.
  • 브라우저는 자신의 오리진과 백엔드 API 서버로부터 전송받은 Access-Control-Allow-Origin 헤더가 일치하거나 *라면 응답이 허가된 것으로 간주하고 데이터를 로딩.
  1. 미왕론 FE 회의
  • 깃 관련
    1. 이슈 컨벤션
    2. 커밋 작성 규칙
    3. 커밋 주기: 하루에 한 번은 꼭 날리기
    4. 포크, 클론 방식: 포크
    5. 템플릿 작성해서 pr 올리기
  • 레이아웃 관련
    1. 공통 컴포넌트
      1. 헤더 왼쪽 화살표 유무? display에 따라서 주기
      2. input 창 공유하기
    2. 메인 페이지
      1. 슬라이드 불렛 긴 걸로
      2. 메뉴 아이콘 열렸을 때 내용 변경: 로그인, 마이페이지, 필터별 이동, 장바구니, 관심 상품
    3. 회원 가입 / 로그인
      1. 추가 정보는 옵셔널?
      2. 디자인 흰색 박스에 쉐도우 있는 것으로
    4. 상세 페이지
      1. 북마크, 장바구니 아이콘 추가
    5. 이용 중인 대출 상세 페이지
      1. 상품 상세 페이지와 UI 맞추기 상단 높이 같고, 하단 콘텐츠 사이즈 맞추기
    6. 마이 페이지
      1. 관심 상품 개수 제한
      2. 로그인 안 했을 때 관심 상품 담을 수 있게?
    7. 로딩 페이지
      1. 애니메이션화
  • API 명세 추가해야 될 것
  • CSS global style
    • --black-10: #e6e6e6;
      --black-20: #ccc;
      --black-30: #b3b3b3;
      --black-40: #999;
      --black-50: #808080;
      --black-60: #666;
      --black-70: #4c4c4c;
      --black-80: #333;
      --black-90: #191919;
      --black-100: #000;
    • btn 스타일 지정
      • radius: 50%
    • input 스타일 지정
      • radius 50%
    • 기타 박스
      • radius: 20px
    • global shadow 값 지정
  • 폰트: 프리텐다드
  • react toastify
  • 백엔드와 이야기해 봐야 될 것
    1. 결제를 하지 않는데 이용 중인 대출이 뜨게 할 것인지?
      1. 회원 가입할 때 기본적으로 이용 중인 대출이 있게 할 수 있는지?
  • 1차 멘토링 기간 질문할 것
  • 일정 정리
    1. ~16일 UI 마크업
    2. ~22일 API 연결 및 오류 정리
    3. ~24 배포

💚 2월 13일 월요일

  1. 리액트 퀵 스타트

프록시

프론트엔드 애플리케이션을 호스팅하는 서버에 프록시를 설치하여 프론트 서버의 프로시를 거쳐서 백엔드 API와 통신하도록 하여 브라우저 측에서는 동일한 오리진과 통신하도록 하는 방법.

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
//https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      "/api": {
        target: "http://localhost:8000",
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, ""),
      },
    },
  },
});

CRA에서 프록시 설정 방법

// src/setupProxy.js
const { createProxyMiddleware } = require("http-proxy-middleware");
module.exports = function (app) {
  app.use(
    "/api",
    createProxyMiddleware({
      target: "http://localhost:8000",
      changeOrigin: true,
      pathRewrite: {
        "^/api": "",
      },
    })
  );
};

axios 라이브러리 사용법

  1. axios.get()
  • GET 요청 처리를 수행해 주는 axios 함수.
  • url: 요청하는 백엔드 API의 url을 지정.
  • config: 요청 시에 지정할 설정 값.
  • 요청 후에는 Promise를 리턴하며 처리가 완료된 후에는 response 객체를 응답받는다.
  • axios.get(url, config)
  • 응답 객체의 속성
    • config: 요청 시에 사용된 config 옵션
    • data: 수신된 응답 데이터
    • headers: 백엔드 API 서버가 응답할 때 사용된 응답 HTTP 헤더
    • request: 서버와의 통신에 사용된 XMLHttpRequest 객체의 정보
    • status: 서버가 응답한 HTTP 상태 코드
    • status Text: 서버의 HTTP 상태를 나타내는 문자열 정보
  1. axios.post()
  • POST 요청을 처리를 수행해 주는 axios 함수.
  • url, config는 axios.get()과 동일.
  • data는 POST 요청의 HTTP Content Body로 전송할 데이터.
  • axios.post(url, data, config)
  1. axios.put()
  • axios.put(url, config)
  1. axios.delete()
  • axios.delete(url, data, config)

axios 기본 설정 변경

  • axios.defaults.baseURL = '/api/todolist_long'
    • 기본 경로를 사용했다면 axios.get('/gdhond')과 같이 사용할 수 있다.
  • axios.defaults.headers.common['Authorization'] = JWT
    • 인증 토큰은 백엔드 API 요청 시 항상 전달하므로 기본값으로 설정할 수 있다.
  • axios.defaults.timeout = 2000
    • timeout에 설정된 시간 내에 응답이 오지 않으면 연결을 중단(abort)시킨다.
  1. 백준
  1. 그룹 스터디
  2. 미왕론
  • 피그마 최종 수정
  • UI 마크업 시작!

💙 2월 14일 화요일

  1. 미왕론 전체 회의
  2. 리액트 퀵 스타트

플럭스 (flux)

대규모 애플리케이션에서 일관된 데이터 관리를 손쉽게 하기 위해 만들어진 단방향 데이터 처리 과정을 가지는 아키텍처. 플럭스 아키텍처는 단일 디스패처를 이용. 모든 데이터 흐름은 단일 디스패처를 거쳐 가므로 이곳에서만 모니터링과 로깅을 하면 모든 액션의 흐름을 볼 수 있으며, 액션에 의해 상태가 어떻게 변경돼가는지를 손쉽게 추적 가능.

  1. 뷰 컴포넌트(리액트 컴포넌트)에서 이벤트가 발생하면 이벤트 핸들러에 의해 액션 생성자(ActionCreator)가 호출.
  2. 액션 생성자는 외부 API 호출과 같은 부작용 (side effect) 처리를 수행하고 수행 결과를 action이라는 일종의 객체 형태의 메시지를 생성하여 디스패처(dispatcher)에 전달. {type: "addTodo", payload: {todo: "공부하기", desc: "리덕스"}}
  3. 디스패처는 액션을 스토어에 전달. 스토어는 액션 정보를 이용해 지정된 상태 변경 작업을 수행.
  4. 상태가 변경되면 각 스토어와 연결된 컴포넌트의 UI가 갱신.

리덕스 (Redux)

리덕스는 댄 아브라모프라는 개발자가 만든 자바스크립트 애플리케이션을 위한 예측 가능한 상태 관리 컨테이너. 플럭스의 기능과 더불어 핫 리로딩 (hot reloading), 시간 여행 디버깅(time travel debugging)과 같은 기능을 제공.

리덕스의 스토어는 상태만 가지고 상태 변경의 기능을 리듀서라는 요소로 분리. 이 결과 변경 로직이 개발 중에 변경되더라도 상태를 유지시킬 수 있다. 이 기능을 핫 리로딩이라고 한다. 리듀서를 이용해 상태를 변경할 때 기존 상태 객체를 변경하지 않고 새로운 상태 객체를 생성한다.

리덕스의 불변성을 가지는 상태 변경은 시간 흐름에 따라 상태의 이력을 남긴다. 상태 변경 이력은 시간 흐름에 따라 상태가 어떻게 변경됐는지 손쉽게 추적할 수 있게 해 준다. 그리고 애플리케이션 개발 중에 과거의 어느 한 시점의 상태로 돌아가서 다시 기능을 확인할 수 있어 디버깅에 유용하다. 이런 디버깅 기능을 시간 여행 디버깅이라고 한다.

리덕스 아키텍처와 처리 과정

  1. 스토어의 상태와 액션 생성자를 이용한 디스패치 기능의 함수가 주입된 뷰 컴포넌트에서 이벤트가 발생.
  2. 뷰 컴포넌트의 이벤트 핸들러는 속성으로 주입된 함수가 호출되며, 이때 action을 만들어서 스토러오 전달(dispatch). 액션의 형태는 플럭스 아키텍처에서 사용하던 것과 유사.
  3. 스토어는 전달받은 액션과 자신의 상태를 리듀서 함수의 인자로 전달. 리듀서는 다음과 같은 형식의 함수. (state, action) => {...}
  4. 리듀서는 인자로 전달받은 상태는 변경하지 않고, action을 이용해 새로운 상태를 만든 뒤 리턴 합니다.
  5. 스토어는 리듀서가 리턴한 상태를 새로운 상태로 설정. 스토어의 새로운 상태는 뷰 컴포넌트에 연결되어 있으므로 화면이 새롭게 렌더링 된다.

리덕스 구성 요소

리덕스 아키텍처에서 스토어는 단 하나이다. 스토어의 상태는 읽기 전용, 상태 변경은 리듀서에 의해서만 수행해야 한다. 리듀서는 여러 개 만들 수 있는데 상태 변경 로직을 포함하면서 더불어 스토어가 가지는 초기 상태를 전달해 주는 역할을 한다. 리듀서는 순수 함수여야 한다.

💜 2월 15일 수요일

  1. 백준
  1. 리액트 스터디
  2. 미왕론
  • 메뉴바에 대한 고찰...
  • 유틸에 있는 회원 정보로 수정
  • 추가 정보 셀렉트 추가
  • 관심 상품 아이콘 추가
  • API 관련
    • 회원 정보 수정 API 없음
    • 회원 정보 조회할 때 이용 중인 대출 더미 데이터 API 없음
    • 상품 번호 SNQ?
    • 관심 상품 추가, 삭제 API 없음
    • 관심 상품 응답 값 변경
    • 로그인 토큰 쿠키로 저장?
    • 회원 정보 조회 때 비밀번호 안 불러와도 됨

🤎 2월 16일 목요일

  1. 백준
  1. 미왕론
  • 마이페이지에 필요한 API 연결 중
  1. 리액트 퀵 스타트

다중 리듀서

리덕스 미들웨어

액션이 스토어로 전달된 후 리듀서에 도달하기 전과 상태 변경이 완료된 후에 수행할 중앙집중화된 작업을 지정할 수 있는 함수. 리덕스 미들웨어는 스토어 내부에 등록한다. 리덕스가 단일 스토어 아키텍처이기 때문에 스토어에 들여다 볼 수 있는 요소를 설치하면 모니터링, 비동기, 로깅 등의 다양한 작업을 수행할 수 있는데, 스토어에 설치하는 요소가 리덕스 미들웨어이다.

middleware(store)(next)(action) 이런 형태의 커링 함수(curring)를 사용하게 되는데 store는 리덕스 스토어, action은 스토어로 전달되는 액션 메시지, next는 dispatch() 함수이다. 한 미들웨어에서 리듀서로 전달하기 전의 실행이 완료되면 next(action)을 호출하여 다음 리듀서로 action을 전달해 줄 수 있다. 만약 액션을 전달해 주지 않으면 다음 미들웨어는 물론이고 리듀서로 액션이 전달되지 않으므로 상태를 변경하지 않을 것이다.

미들웨어를 추가하려면 순서대로 concat()함수로 추가한다.

@reduxjs/toolkit은 직렬화 가능 여부, 불변성 제공 여부를 체크하는 내장된 기본 미들웨어와 비동기 처리를 위한 redux-thunk 기능을 제공하는 미들웨어를 내장하고 있다. 해당 프로젝트의 Date 타입을 사용하는 currentTime은 직렬화가 지원되지 않으므로 경고가 발생할 수 있으므로 serializableCheck 옵션을 false로 지정하였다.

loggerMW의 내용을 개발할 때 확인할 수 있는 것

  • 전달된 액션
  • 전달된 액션에 의해 변경되기 전의 상태
  • 전달된 액션에 의해 변경된 후의 상태

redux-thunk 미들웨어

리듀서는 비동기 처리 코드를 배치하지 않는다. 왜냐하면 리듀서는 상태를 변경하는 기능만을 작성해야 하며, 순수 함수여야 하기 때문이다. redux-thunk는 액션 대신에 thunk라는 함수를 전달(dispatch)하도록 하여 비동기 처리를 수행하는 기능을 제공하는 미들웨어이다. 지연된 연산을 실행하기 위해 표현식으로 만든 함수라고 할 수 있다.

  1. dispatch(action)이 호출되면서 스토어로 액션이 전달.
  2. redux-thunk 미들웨어를 거치면서 전달된 액션이 thunk 형태의 함수인지를 확인.
  3. 이때 thunk라면 thunk() 함수 내부에서 비동기 처리 코드를 실행, 이 과정에서 상태를 변경할 수 있는 액션을 전달.
  • 이 함수 내부에서 비동기 처리가 시작되었음을 나타내기 위한 상태 변경 액션을 전달(dispatch)
  • 비동기 처리가 완려되면 처리 결과를 화면에 나타내기 위한 상태 변경 액션을 전달(dispatch)
  1. thunk가 아니라면 next(action)을 호출해 리듀서가 새로운 상태를 만들어내도록 한다.

createAsyncThunk() 사용 방법

const asyncAction = createAsyncThunk("액션명", asnyc (arg, thunkAPI) => {
  // arg는 비동기 처리할 때 필요한 아규먼트
  // 비동기 처리 후 마지막에 리턴 하는 값이 최종적으로 완료했을 때 전달하는 action의 페이로드가 된다.
  return payload
})

createAsyncThunk 툴킷 함수의 특징은 시점별로 직접 dispatch(action) 하지 않아도 된다는 것.
리턴 받은 함수의 이름이 asyncAction 이고 액션명이 searchPerson으로 지정했다면 각 시점의 액션 생성자 함수와 액션이 사용하는 액션명은 아래와 같다.

시점액션명액션 생성자 함수
비동기 작업 시작searchPerson/pendingasyncAction.pending
비동기 작업 완료searchPerson/fulfilledasyncAction.fulfilled
비동기 작업 실패searchPerson/rejectedasyncAction.rejected

createAsyncThunk() 람수에 전달되는 두 번째 인자인 payloadCreator 함수는 Promise 기반이므로 async/await이나 Promise 기반으로 작성해야 한다.

백엔드 API 요청 redux-thunk와 axios 사용하기

  1. 멘토링

프로젝트 관련 질문

  1. 적응형 웹? 반응형 웹?
  2. apple break point 참고해 보기 360px을 최소로 잡는 거 나쁘지 않다
  3. 미디어 쿼리에 따른 px 지정해 두는 것도 좋다 rem과 px는 상황에 따라 다름
  4. 360 > 390 > 480 순으로 breakpoint를 두는 편
  5. 어느 정도 작업이 되었다면 모바일로 확인해 보기
  6. React.memo = UI 관리
  7. 해당 프로젝트에서 useMemo 쓸 일은 딱히 없을 듯
  8. useCallback은 콘솔을 찍어 보고 필요 없는 렌더링에 걸면 좋음!
  9. 로그인 할 때 제대로 된 값이 아닌데 넘어가거나 이런 사소한 에러 처리를 많이 해 보는 것이 좋음
  10. axios 쓸 때 interceptor을 사용해 보자

취업 관련

  1. 현업에서 tailwind 쓰는 곳 많이 없을 듯
  2. 원티드나 사람인 이런 곳도 좋지만 프로그래머스, 네이버 채용, 카카오 채용도 꼭 보길
  3. 블라인드 확인해 보기
  4. 인프런 이력서 멘토링 이용해 보기
  5. 여러 회사에 면접을 보고 합격을 받아 두는 것 > 연봉 협상에 아주 좋음
  6. 포폴에 프젝 설명, 담당 업무, 트러블 슈팅, 최적화 경험 작성하기

코딩 테스트

  1. PCCP 비추임
  2. bfs, dfs, dp (네이버, 라인에서 많이 냄)
  3. 자료 구조 (큐, 스택) 같은 것들은 당연히 알아야만
  4. map, set 알아 두기
  5. map과 object의 차이점, 장단점
  6. 프로그래머스 데브 매칭
    1. 여기 있는 연습 과제 해 봐야 될 듯

CS 질문 많이 받았나요?

  1. HTML 아웃라인 알고리즘
  2. doctype 작성하는 이유?
  3. 시멘틱 태크
  4. transform translate vs position
  5. CSS 쌓임 맥락
  6. 브라우저 렌더링 동작
  7. 호이스팅, 클로저
  8. 실행 컨텍스트
  9. 렉시컬 환경
  10. class component vs function component
  11. setTimeout vs promise vs requestAnimationFrame 실행 예측 문제

2. 주간 회고

새해가 되고 나서 시간이 더 빠르게 가는 것만 같다! 미니 프로젝트를 처음 받았을 때는 빨리 끝낼 수 있다고 생각했는데 막상 시작하고 나니 신경 쓸 것도 많고 내가 하고 싶은 것들도 많아져서 더 많은 노력을 해야 될 것 같다. 내가 조장이 아닌 조는 상상할 수 없다는 수강생들의 말을 들으면서 내가 더 잘하고 팀장으로서 노력을 해야 되겠다는 생각이 절실했던 한 주였다. 그리고 목요일에 진행한 멘토링에서 면접과 관련해서 많은 이야기를 들을 수 있어서 도움이 됐다. 요즘 포트폴리오 어떻게 작성하면 좋을지 고민 중인데 아직 방향성이 제대로 잡힌 건 아니지만 그래도 포트폴리오를 만들면서 도움이 될 것 같았다. 그리고 면접에서 받은 CS 질문 관련해서도. 기초적인 질문이지만 기억해 두지 않으면 자주 까먹는 것들인 것 같았다. 아좌좍.

지금까지 23주차의 기록을 읽어 주신 여러분, 감사합니다! 김당퀔은 이만 공부하러. 🥕🥕

profile
당근 먹는 쿼카
웅냥냥
이전 포스트

[패스트 캠퍼스] MegaByte School 프론트엔드 3기 회고 - 22주차

다음 포스트

[패스트 캠퍼스] MegaByte School 프론트엔드 3기 회고 - 24주차

0개의 댓글