const allQueriesResolved = results.every(result => !result.isPending && !result.isLoading);

react-query의 useQueries를 통해 API 통신 결과를 받아와서 상태가 pending이나 loading이 아닌 경우들을 파악하려고 했는데 통신을 하지 않은 상태에서도 allQueriesResolved변수가 true라서 원인을 찾던 도중.....every는 빈배열일 때 콜백함수에 관계없이 true를 반환한다는 것이었다..

...........왜?

당연히 results가 빈 배열일 때 콜백함수 조건을 만족하지 않으니까 every가 false일 줄 알았지....너무나도 삽질이었다..

검색해보니 너무나도 자세히 설명되어있는 포스트를 찾았다.

(번역) 이상한 자바스크립트: 왜 every()는 빈 배열에 true를 반환할까?

전체 양화사...공허참...주어진 조건을 만족시킬 수 없는 경우 공집합은 참을 의미한다.

빈배열이라면 길이가 0 이기 때문에 5번 과정이 생략되어 콜백함수를 호출할 수 없게되고 true를 return한다..

return results.length === 0 ? false : allQueriesResolved;

결국 every로 배열 요소들의 조건을 파악하기 전에 해당 배열이 빈배열인지 먼저 확인해야한다! 삽질했지만 절대 안까먹을 것 같다...

📌 먼저, CORS란 무엇인가

CORS(Cross-Origin Resource Sharing) : 교차 출처 리소스 공유

우선 브라우저는 동일출처정책(SOP)에 따라 동일한 출처에서만 리소스를 공유할 수 있게 되어있다. 그런데 만약 https://www.naver.com 에서 https://www.google.com , http://www.naver.com 에 있는 리소스를 공유하려고 할 때 출처(Origin), 즉 protocol, host, port가 다른 곳에서 리소스를 요청하게 된다.

교차 출처에서 리소스를 요청하게 된다면 응답받는 origin의 서버단에서는 200 ok를 던져주게 된다. 서버단이 아니라 브라우저에서 판단하기 때문에 브라우저에서 '엇, origin이 다르네?' 하고 CORS 정책을 확인하고 위반한 요청일 경우 접근을 막아버리는 것이다.

이것이 우리가 익히 아는 CORS 에러이다.

📌 어떻게 해결할 수 있는가

✔️ 백엔드단에서 해결하기

백엔드 개발자에게 부탁하기..

서버에서 Access-Control-Allow-Origin 헤더에 요청하는 주소를 정확히 명시해 '해당 주소는 접근을 허용한다' 라고 브라우저 쪽으로 알려주면 된다.

Access-Control-Allow-Origin: * 로 어떤 주소든 접근을 허용하겠다고 명시해도되지만 보안상의 이슈가 있어 지양하는 것이 좋다.

✔️ 프론트단에서 직접 해결하기

인증 정보로 쿠키를 사용한다면 ?

CORS는 기본적으로 쿠키의 사용을 막고있기 때문에 쿠키 허용 설정을 안해주었을 경우에도 CORS에러가 발생할 수 있다. 인증 정보로 쿠키를 사용한다면 요청, 응답 시 credentials 부분을 true로 설정해주어야 한다.

요청(클라이언트)

fetch 메소드 인 경우

fetch(url, {
  credentials: 'include'
}) 

axios 라이브러리를 사용하는 경우

axios.post(
    'https://example.com:1234', 
    { withCredentials: true }
).then(response => { 
})

응답(서버)

// node, express 기준
const cors = require('cors');

const app = express();

app.use(cors({
    credential: 'true'
}));

프록시 설정하기

// package.json 파일
{ ... 
"proxy" : "우회할 API 주소"
}

CRA로 설정한 프로젝트에서는 package.json에 해당 방식으로 proxy를 설정할 수 있다. 우회할 API 주소가 여러개라면 http-proxy-middleware 라이브러리를 사용해서 프록시를 설정할 수도 있다.

http-proxy-middleware 라이브러리는 로컬환경에서만 잘 돌아간다...

잊을만하면 괴롭히는 CORS에러... 하나씩 시도하면서 해결하면 될것이다!

MSW(Mock Service Worker)란?

서비스 워커(Service Worker)를 사용하여 HTTP 네트워크 호출을 가로채는 API 모킹(mocking) 라이브러리

백엔드에서 받는 API인 척 실제 네트워크가 이루어지는 것 처럼 프론트엔드의 응답값을 주는 라이브러리이다.

실제 네트워크단에서 일어나기 때문에 axios의 호출하는 엔드포인트나 REST API를 실제 API로 바꿔기기 쉬우며 에러처리나 예외처리를 똑같이 수행할 수 있다는 점이 굉장히 매력적이다.

MSW 사용법

1. 라이브러리 설치하기

저는 yarn을 사용하므로 yarn 커맨드로 설치

yarn add msw --dev

2. Service worker 등록

아래 명령어를 통해 msw라이브러리를 실행시켜 public 폴더 위치에 worker를 등록한다.

npx msw init public/ --save

3. worker 설정

// src/mocks/browser.ts

import { handlers } from "@mock/handlers/handlers";
import { setupWorker } from "msw";

export const worker = setupWorker(...handlers);

worker 인스턴스를 생성하고, 요청 핸들러를 정의한다.

4. worker 실행

// src/main.ts
import initMockAPI from '@mock/index.ts';
import ReactDOM from 'react-dom/client';
import { RecoilRoot } from 'recoil';
import App from './App.tsx';

initMockAPI();

ReactDOM.createRoot(document.getElementById('root')!).render(
  <RecoilRoot>
    <QueryClientProvider client={queryClient}>
      <App />
    </QueryClientProvider>
  </RecoilRoot>
)

// src/mocks/index.ts
const initMockAPI = async (): Promise<void> => {
  if (import.meta.env.VITE_REACT_ENV === '2') {
    const { worker } = await import("@mock/browser");
    worker.start();
  }
};

export default initMockAPI;

가장 최상단 루트파일인 main.ts에 worker 실행 코드를 추가한다. (나는 개발환경에서만 worker를 실행하기 위해 환경변수를 통해 실행을 제어했다.)

이제 yarn dev로 어플리케이션을 다시 실행시키면 콘솔에서 메세지가 뜨면서 활성화가 된다 !

5. 요청 핸들러 작성

그럼 이제 네트워크 호출을 가로챌 준비는 끝났고 어떤 요청을 했을 때 어떤 응답값을 받아야하는지에 대한 정보를 나타내는 요청 핸들러를 작성해주어야한다.

// src/mocks/handlers/handlers.ts

export const handlers = [
  rest.get('/result', (req, res, ctx) => {
    const DataEnc = req.url.searchParams.get('DataEnc');
    const pageNum = req.url.searchParams.get('pageNum');

    if (!DataEnc) {
      return res(ctx.status(301, 'dataenc값 없음'));
    }
    if (pageNum === '0') {
      return res(ctx.json(pageData_0));
    } else if (pageNum === '1') {
      return res(ctx.json(pageData_1));
    } else if (pageNum === '2') {
      return res(ctx.json(pageData_2));
    } else if (pageNum === '3') {
      return res(ctx.json(pageData_3));
    } else if (pageNum === '4') {
      return res(ctx.json(pageData_4));
    } else if (pageNum === '5') {
      return res(ctx.json(pageData_5));
    } else if (pageNum === '6') {
      return res(ctx.json(pageData_6));
    } else {
      return res(ctx.json(pageData_7));
    }
  })
]

rest객체를 사용하여 get, post, put, delete 등 API에 해당하는 http메소드들을 불러올 수 있다.

응답 해석기

req는 요청정보, req는 응답 정보, ctx는 status code, headers, body 등 응답값들을 지정한다.

query parameter

req.url.searchParams.get를 통해 URLsearchparams로 넘겨준 querystring을 가져올 수 있고 파라미터별 값 분기처리를 통해 로직을 구현한다.

postman을 통해 API response값의 key와 value의 형식만 지정해주면 되기 때문에 이제는 더이상 API에 구애받지 않고 프론트엔드 개발을 할 수 있었다 !! mock data보다 초기 코드작성이 많고 진입장벽은 높았지만 host를 변경해줘야하거나 상태코드에 따른 로직을 구현할 수 없었던 단점을 보완할 수 있어서 너무 좋았고 실제 API통신과 흡사해서 UI 구현하는데 너무 편리했다 ✨

window.performance.getEntriesByType("navigation")[0].type의 'back_forward'값으로 뒤로가기 접근 감지로직을 만들었는데 해당 이벤트가 발생하지 않았다.. console.log를 찍어도 해당 인터페이스의 객체 자체가 찍히지 않는 것이었다. 페이지 이동 시에 문제가 있는 것 같아 이것저것 시도해보았다.

의심 1. 새로고침?

페이지 이동 시 새로고침이 안되어서 그런지 첫번째 의심을 해봤다. useNavigation으로 이동을 하고 있었는데 새로고침을 해주기 위해 replace: true 옵션을 주었다. 새로고침은 되었으나 이것 역시 원인이 아니었다.

의심 2. 페이지 이동 자체의 문제

navigate의 문제가 있는게 아닐까 하여 location.replace()로 변경해주었다.

드디어 console.log에 객체가 떴다 !! 😊

그렇다면 useNavigate() / location.place()는 어떤 차이점이 있는걸까?

1. useNavigate()

React-Router v6에서 제공하는 navigate훅으로 React앱 내부의 navigate, 이동 히스토리를 관리할 수 있다. 따라서 useNavigate를 사용해 페이지를 이동하는 것은 React앱 내부에서의 이동일 뿐 실제 크롬, 사파리 브라우저의 히스토리에는 영향을 주지 않는다.

2. location.place()

location.place는 자바스크립트 내장 함수로 실제 브라우저의 navigate, 이동 히스토리를 관리할 수 있다. location.href와는 달리 페이지 이동 시에 새로고침까지 이루어지는 함수이다.

💡 useNavigation은 React Router를 통해 React내의 history를 조작하는 것 뿐 실제 브라우저의 history에는 관여하지 않아 window.performance이벤트가 발생하지 않았다 !!

시간복잡도를 나타내는 표기법 중 하나로 'O(입력)'으로 표기합니다.

빅오로 표현할 수 있는 시간복잡도의 코드는 아래와 같습니다.

1. O(1)

'일정한 복잡도'라고 하며, 입력값의 크기와 관계없이 즉시 출력값을 얻어낼 수 있는 시간복잡도 입니다.

function O_1_algorithm(arr, index) {
  console.log('o1 알고리즘!');
}

코드와 같이 함수 파라미터를 통한 입력값을 통해 바로 출력값을 얻었을 때 시간복잡도가 O(1)입니다.

2. O(n)

'선형 복잡도'라고 하며, 입력값이 증가함에 따라 시간 또한 같은 비율로 증가하는 것을 의미하는 시간복잡도 입니다.

function O_n_algorithm(n) {
  for (let i = 0; i < n; i++) {
    console.log(i)
  }
}

코드와 같이 n=1이면 i=0일 때 1초 실행시간, i=1일때 1초 실행시간, 이렇게 n이 1씩 증가할 때마다 실행시간이 1초씩 증가합니다.

즉, 입력값이 증가함에 따라 시간 또한 같은 비율로 늘어나는 시간복잡도가 O(n)입니다.

3. O(n^2)

'2차 복잡도'라고 하며, 입력값이 증가함에 따라 시간이 n의 제곱수 비율로 증가하는 것을 의미하는 시간복잡도 입니다.

입력값이 1일 때 1초의 실행시간이 걸리던 알고리즘에 3일 때 9초가 걸리는 것을 의미합니다.

function O_n2_algorithm(n) {
  for (let i = 0; i < n; i++) {
    for (let j = 0; j < n; j++) {
      console.log(i, j)
    }
  }
}

n=3이라고 한다면 i=0,1,2 j=0,1,2 총 9회의 for문이 돌아가고 총 실행시간이 9초이다.

이처럼 입력값이 증가함에 따라 시간이 제곱으로 증가하는 시간복잡도가 O(n^2)입니다.

4. O(2^n)

'기하급수적 복잡도'라고 하며, 가장 느린 시간 복잡도를 가집니다.

이 시간복잡도의 가장 대표적인 알고리즘은 피보나치 수열입니다.

function O_2n_algorithm(n){
  if(n <= 0) {
      return 0;
  } else if(n === 1) {
      return 1;
  }
      return O_2n_algorithm(n-1) + O_2n_algorithm(n-2);
}

즉 함수를 호출할 때마다 바로 전 숫자와 그 전 숫자를 알아야 숫자를 더하면서 앞으로 나올 숫자를 파악할 수 있습니다. 이렇게 매번 함수가 호출될 때마다 두 번씩 호출합니다. 이걸 트리의 높이만큼 반복합니다.

5. O(log n)

해당 시간복잡도는 한번 처리할 때마다 탐색량이 절반씩 줄어듭니다.

let arr = [];

function O_logn_algorithm(k, s, e){
  for(let i = s; i <= e; i++){
    arr.push(i);
    let m = (s+e)/2;

    if(arr[m] === k){
      console.log(m) 
    } else if(arr[m]> k){
      return log(k, s, m-1);
    } else{
      return log(k, m+1,e)
    }
  }
}

해당 시간복잡도의 가장 대표적인 알고리즘은 이진 탐색입니다. 배열에서 특정 숫자를 찾을 때, 이진 탐색을 이용한다면 배열 가운데 값과 키값을 비교하고 가운데 값이 키값보다 작다면 탐색하지 않습니다. 그럼 다시 또 중간값을 설정하고 비교합니다.

6. O(n log n)

해당 시간복잡도는 퀵 정렬, 병합 정렬과 같은 분할 정복 정렬 알고리즘의 실행 시간입니다.

function O_nlogn_algorithm(arr) {
  if (arr.length <= 1) return arr;

  const pivot = arr[0];
  const left = [];
  const right = [];

  for (let i = 1; i < arr.length; i++) {
    if (arr[i] <= pivot) left.push(arr[i]);
    else right.push(arr[i]);
  }

  const lSorted = quickSort(left);
  const rSorted = quickSort(right);
  return [...lSorted, pivot, ...rSorted];
};

이전 문제에 있었던 퀵 정렬을 예로 들어보겠습니다. 기준값이 되는 피벗 포인트를 설정하고 해당 값보다 작은 배열, 큰 배열이 나뉘고 또 그 배열안에서 기준값을 정하고 해당 값보다 작은 배열, 큰배열 이렇게 분할 정복으로 계속 나뉘게 됩니다.

이 때의 시간복잡도가 O(n log n)입니다.

해당 에러는 Nginx 자체 클라이언트 쪽 에러로 서버가 응답을 보내기도 전에 클라이언트쪽에서 연결을 끊어버린 상태다

아니 나는 끊은 적이 없는데 왜...? 🥲

원인을 찾다보니 React-Query useMutation의 mutateAsync로 비동기처리를 하고 있었는데 axios의 timeout시간에 딱 걸려버린 것이다. 해당 api가 1.5초 정도 걸렸는데 1초로 해줬으니 axios에서 응답을 받기도 전에 끊어버린 것이다.

✏️ timeout시간을 1초에서 3초로 늘려줬더니 해결 !

1. 'react-scripts: not found' 에러🥲

역시 한번에 될리가 없지.....뭐가 문제니ㅠㅠ react-script를 찾을 수가 없다는 에러다...왜? why? 이런 바보... npm install을 하지 않아서 package.json내의 파일들을 다운로드 하지 못해 react-script를 알지 못하는거였다. workflow에 run:npm install 추가해주면 된다 😎 그러나 찾아보니 npm install 대신 npm ci를 추천해주더라. 빌드 시에 package-lock.json을 수정하지 않고 정확한 버전의 패키지들을 설치해 node_modules에 적재하기 때문에 버전이 동일하다는 이유에서다!

2. React 18에서 @testing-library/react-hooks not support?!

npm ci로 바꾸기 전 npm install을 추가했음에도 불구하고 에러가 났다.. @testing-library/react-hooks에서 해당 @types/react를 찾을 수 없다는거 였는데 package-lock.json을 보니 16, 17버전 의존성만 있고 18이 없었다..!!! 공식 github을 가서 봤더니 Readme에 React 18에서는 @testing-library/react에서 한번에 지원하고 있으니 react-hooks는 Uninstall해도 된다고 나와있었다.(이것이 Readme의 중요성인가..) 삭제하고 다시 Install하니 정상적으로 되었다 😊

3. eslint warn 규칙때문에 build fail 에러🥲

이젠 정말 다 된줄 알았어...ㅎ 협업을 위해 설정한 eslint룰 중에 warn으로 지정해준 것들 때문에 build가 fail난다.. 어차피 우리는 eslint error로 지정해둔 규칙들 중 하나라도 어기면 push를 못하게하는 husky를 지정해놨기때문에 여기서는 eslint를 무시하도록 하기로 했다. CI가 false일 때 npm run build를 해주게끔 workflow를 수정해주면 된다! 흠 근데 env에 CI=false로 하면 안되고 npm run build 옆에 지정해주어야 된다...왜일까

1. AWS S3

배포를 도와주는 많은 툴들이 있지만 그 중에 보편적으로 사용하는 AWS의 S3를 활용해보자. 먼저 AWS란 현재 가장 보편적으로 사용되는 클라우드 컴퓨팅 서비스로 그 중 S3는 특정 파일을 저장해 인터넷상에서 접근할 수 있도록 해주는 서비스이다.

CRA로 React환경을 구축하고 빌드하면 build파일들이 생성되고 이를 브라우저에서 접근해서 실행하면 CSR의 특징으로 S3서비스를 통해 배포할 수 있다.

2. AWS S3로 배포해보기

2-1. AWS 계정 생성

배포를 하려면 일단 AWS 계정을 먼저 생성한다 ! 신용카드 등록 해야해서 유료인가하지만 프로젝트 배포정도는 무료이고 인증용으로 돈을 가져갔다가 다시준다 ㅎ

그 후 콘솔에서 S3에 접속한다.

2-2. 버킷 생성

버킷 이름을 설정하고 버킷을 저장할 AWS리전을 선택한다. 보통의 토이 프로젝트 같은 소규모 같은 부분은 우리나라 한정에서만 접근하면 되니까 전세계에 있는 AWS 서버 중 서울에 있는 곳으로 지정해준다.

그 뒤로 우리는 해당 배포 URL을 알고있는 누구나 접근을 허용해야하므로 기본적으로 설정되어있는 엑세스차단 체크를 풀어준다. 퍼블릭 상태가 될 수 있음을 알고 있습니다에는 체크표시 !

2-3. 배포할 파일들을 업로드

만들어진 객체에 배포할 파일들을 업로드해준다. 업로드 버튼을 눌러서해도 되고 drag & drop으로 해도된다. 여기에 업로드 할 파일들은 이전에 말했듯이 빌드하여 생성된 파일들을 업로드 해준다.

업로드 할 파일 객체들에 index.html이 보여야한다 ! (그 위 상위폴더들 xxx)

2-4. 웹 사이트 호스팅 활성화

그 후 속성 탭에 가서 정적 웹 사이트 호스팅을 설정해준다. 활성화 한 후 기본 페이지, 즉 /경로로 들어왔을 경우 보이는 기본페이지다. CSR 기반의 React프로젝트이니까 index.html로 지정해준다. 오류가 발생했을 때 예외페이지도 설정해줄 수 있다.

따단! 활성화를 시키면 배포된 URL을 보내준다!! 이제 한번 웹사이트를 접근해보자!!

🥲...끝날때까지 끝난게 아니었다...왜 안보이니.... 403 error는 권한없음 에러! 나 너 누군지는 알겠어(인증 ok) 그치만 너는 여기에 접근할 권한이 없단다(인가 fail) 요런 말이다. 그렇다면 허락을 해주면 되겠지?

2-5. 버켓 정책 설정

해당하는 Resource, 즉 해당 버킷 ARN에 대해 GetObject(객체를 가져오는 행동)을 허락하겠다.라는 의미의 정책을 설정해주었다. (Sid는 해당 정책에 대한 unique한 id로 무슨 역할을 하는 정책인지에 대한 것들이 드러나게끔 설정해준다.)

이렇게하면 드디어 웹사이트에 페이지가 등장!!!! 이제 아까 받은 URL로 우리나라 어디에서 접근하든 빠르게 내 프로젝트를 확인할 수 있다 😎

실무에서도 이렇게 하는지는 잘 모르겠다.(엑세스 차단을 해제해도 문제가 없을까..?) 일단 이렇게하면 AWS S3에 배포는 성공적으로 끝마쳤다. 그렇다면 해당 프로젝트가 수정될때마다 AWS 사이트에 들어가서 버킷에 들어가서 다시 파일들을 업로드하는 이런 귀찮은 짓을 해야할까?ㅠㅠㅠ

역시 개발자는 자동화...배포를 자동화하여 지속적인 배포(CD)를 구축해보자!

3. Github Action을 이용한 지속적인 배포

출처: GitHub Actions 공식문서(https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)

github action은 이러한 과정을 거치는데 이 과정을 workflow라고 한다. push, pull request open, issue open등의 특정한 활동을 Event라고 부르며 Event가 발생했을 때 Runner가 동작한다. Runner는 workflow를 실행할 서버를 의미하며 직접 컴퓨터를 관리할 필요없이 가상의 Runner에서 workflow를 실행시킬 수 있다. 하나의 Runner에는 여러개의 Job이 존재한다. Job에는 자주 사용되는 기능들을 모아둔 Action을 등록할 수 있다. 설정파일에서 use 키워드와 함께 사용할 수 있으며 브랜치로 체크아웃하고, 환경을 설정하는 등 복잡하지만 자주 사용되는 과정들을 미리 정의해두고 편리하게 활용할 수 있으며 GitHub Marketplace에서 Action들을 검색하고 활용할 수 있다.

repository를 생성하면 이렇게 Action탭에 workflow를 만들게끔 되어있다. 내 스스로 세팅할 수도 있고 이미 많은 템플릿들도 있어서 선택해서 만들어주면 된다.ㅎㅎ 나는 직접 만들어서 세팅을 해보도록 하겠다.

S3 sync를 맞춰주는 action을 marketplace의 가장 많이 설치된 버전으로 가져와서 등록해보았다.(역시 자동화 좋아하는 개발자들..ㅎ) 해당 workflow는 main브랜치에 push가될 때 npm run build를 실행하고 기존에 버킷에 있던 파일들은 delete한 후 build파일에 있는 파일들을 해당 리전에 있는 해당 버킷에 업로드하겠다라는 의미이다. (workflow만드는건 공식문서에 잘 나와있으니 이것도 참고하기!)

workflow파일은 YMAL형태의 .yml파일로 저장되어야하며 프로젝트파일/.github/workflows/경로안에 위치해있어야한다. env에 보이는 환경파일들은 노출이되면 안되기 때문에 github action에 등록한 후 환경변수를 불러오는 형식으로 불러와준다.

⚠️ 환경변수를 설정하면 다시 들어가도 보여주지 않기 때문에 잘 기억을 해둔다! (accesskey도 마찬가지로 secret accesskey는 다시 알려주지 않는다)

AWS 환경변수 설정하는 곳 ↓

AWS access key 발급하는 곳 ↓

자 이제 해당 repository main 브랜치에 push를 해서 돌려보자!

번외. 에러 핸들링

역시나 마주한 에러들.... 에러 핸들링은 따로 정리해두겠습니다!!

마침내 성공!! 😂

드디어.....드디어..초록빛...!!! 성공적으로 배포를 마쳤습니다!🙏

프론트엔드가 배포까지 알아야하냐구요? 네. 그렇습니다. 프론트엔드도 우리가 만드는 서비스에 책임을 가지고 있어야 합니다. 개발 프로세스를 알고 문제가 생겼을 때 트러블슈팅을 하기 위해 배포를 알아야합니다.💪🏻

🥰 좋았던 점(Liked)

인턴십을 신청할 때 냈던 에세이에서 내가 여기서 얻어가고자 하는 점이 두가지가 있었다.

프리온보딩 인턴십에 참여하여 이루고 싶은게 2가지가 있다.

1. 역량 향상
2. 공유 문화의 경험 실제 기업의 프로덕트를 접해보고 기업 과제를 해결해 봄으로써 실전 역량을 강화시키고 채용과정에서의 기술 과제와 면접에 대한 대비를 할 것이다. 또한 나는 개발자로서 중요한 것이 개발자 간의 공유문화라고 생각한다. 공유를 통해 넓은 인사이트를 가지고 싶기 때문에 많은 동료들과 협업하여 다양한 인사이트의 피드백을 기대한다. 그렇게 되면 스스로의 코드 습관을 알고 나도 피드백을 줌으로써 다른 개발자의 코드를 분석하는 역량을 키우고 싶다.

두개 다 얻었다!! 기술적인 부분, 커뮤니케이션적인 부분에서의 역량을 향상할 수 있었고 코드리뷰를 통한 공유 문화를 경험해 볼 수 있었다.

몹 프로그래밍?

• 몹 프로그래밍....페어 프로그래밍도 아니고 처음 듣는 단어였는데 둘이 아닌 여러명의 개발자들끼리 하나의 디바이스로 같이 프로그래밍을 진행하는 것을 말한다.
• 우리는 서로 다른 곳에서 있는 9명의 사람들끼리 같이 프로그래밍을 진행했다. 처음엔 각자 개발해보고 assignment끼리 묶어서 다같이 디스코드에 모여서 best practice를 도출하는 방향으로 개발을 진행했다. 원래 사공이 많으면 배가 산으로 간다는 말이 있지만...이번에는 이런저런 아이디어들을 많이 엿볼 수 있었고 고집부리는 팀원이 없어서 좋은 부분만 경험할 수 있었던 것 같다!

코드 리뷰

• 팀원들의 실력이 워낙 훌륭해서 배운 점이 많았다. 각자 feature브랜치에서 작업한 후 PR을 올려서 코드리뷰를 진행했다. 조금 더 관심사의 분리를 진행했으면 좋았을 부분, 왜 이렇게 했는지 등 서로 공유했던 부분이 내가 대답하고 물어보면서 한번 더 정리할 수 있었고 내가 미처 생각하지 못한 부분도 발견할 수 있어서 한뼘 성장할 수 있었다.
• github에 issue을 등록하고 commit이랑 PR에 [#이슈번호] 이렇게 태그를 달아서 이슈별로 구분해서 commit과 PR을 볼 수 있어서 너무 좋았다.

husky 도입

• 프로젝트하면서 prettier나 eslint는 사용해봤지만 husky는 처음 시도해보았다. commit전에 컨벤션을 맞췄는지 확인해볼 수 있는 기능으로 warning은 경고창만 error는 아예 push가 안되게끔 할 수도 있었고 팀프로젝트하면서 되게 유용한 기능이었다.

✏️ 배웠던 점(Learned)

양질의 세션과 프로젝트를 진행하면서 기술적인 부분에서 배운 점이 되게 많았다. 해당 내용들을 하나씩 정리해야겠다.

✍🏻 세션 내용 Github Action을 이용한 AWS S3 CD useCallback / useMemo / Context API를 이용한 컴포넌트 렌더링 최적화 의존성 역전을 통해 소프트웨어 유연하게 만들기 TypeScript로 안전하고 표현력이 높은 애플리케이션 작성하는법 Redux의 개념과 미들웨어의 원리 이해하기 Jest와 RTL을 이용해 리액트 컴포넌트 테스트하기 클로저 / 스코프 & 호이스팅의 원리를 실행 컨텍스트와 연관지어 이해하기

🥲 부족했던 점(Leaked)

정보의 홍수..

• 최대한 그 주 세션시간에 배운 내용을 적용하고 싶었지만 알찬 세션 내용으로 정리하고 그 내용을 적용하기까지란 빠듯한 데드라인이었다..차근차근 블로그에 정리해봐야겠다..!

🙏 바라는 점(Longed for)

지금처럼 우직한 궁둥이힘

• 기술적인 부분에서 참 많이 배웠다는 생각이 든다. 오히려 짧은 기간으로 굉장히 몰입할 수 있었고 이렇게 궁둥이를 오래 붙히고 있던 적이 얼마만인가 싶었다. 앞으로 지금처럼 빡 몰입해서 꼭 좋은 곳에 취업하고 싶다 💪🏻

🥰 좋았던 점(Liked)

Notion & Trello & Gitbook

• 이번에는 두번째라 그런지 Notion에 Plan을 계획하는데 익숙해졌고 티켓도 마크업, 스타일링, 기능구현으로 나누어 성취감도 얻고 진척도 파악도 빠르게 할 수 있었다.
• Notion으로 Sprint별 standup meeting기록과 Daily plan을 계획하였고 Trello로 전체적인 개발일정을 관리하였다.
• Gitbook을 통해 API 문서도 그때그때 타협한 내용으로 수정되어 확인할 수 있었다.

Planning Meeting 하나의 Sprint가 시작되는 매주 월요일마다 Trello를 사용하여 해당 Sprint때의 목표를 설정하였다. Daily Standup Meeting 아침 10시마다 전날의 개발진척도와 오늘의 목표, blocker들을 공유하였다. Retrospective Meeting 최종발표 날 두번의 Sprint동안의 KPT회고를 통한 회고를 진행하였다.

standup meeting 10분컷

• standup meeting은 말그대로 서서하는 미팅으로 서서해도 괜찮을만큼 짧게 끝내자는 취지이다.
• 저번에는 진짜 sitdown으로 바꾸자고(ㅎ)할만큼 많은 이야기들을 했었는데 이번에는 미팅 10분전 각자 노션에 진척도, daily todo plan을 얘기해주면서 10분 내로 끝이 날 수 있었다.

기술 공유

• GNB에 모달창을 띄워 가고싶은 지역을 선택하는 UI에서 react-modal 라이브러리 사용법을 팀원에게 공유해주었다! 물론 나의 datepicker가 시급했지만..ㅎ
• CSS를 통해 만들고 있던 팀원에게 공유해주었고 덕분에 시간이 단축이 많이되어 크게는 우리 팀의 개발진척도에도 많은 영향을 줄 수 있었다.

✏️ 배웠던 점(Learned)

공식문서의 중요성

• 죽음의 date picker 라이브러리 사용 시 처음에는 잘 만들어진 예시와 스택오버플로우를 잔뜩 찾아다녔다...그치만 역시 튜닝의 근본은 순정이라고 돌고돌아 공식문서에 답이 있었다.
• 요즘에는 한국어도 많이 제공해주고 데모영상 및 코드박스로 직접 코드를 수정해보면서까지 배울 수 있다.

forwardRef를 통해 DOM요소에 접근

datepicker라이브러리는 input창에 클릭 시 calendar가 띄워지는 형식이다. 이 때의 Input창을 사용자가 직접 custom할 수도 있는데 그 때 forwardRef를 통해 DOM요소에 접근할 수 있다. refprops는 map의 key Prop처럼 특수한 목적으로 사용되고 그 때 forwardRef를 통해 외부에서 받은 ref prop으로 부모 컴포넌트에서 해당 컴포넌트 엘리먼트에 직접 접근할 수 있다.

👇 /src/components/DayPicker/CustomInput.js

const CustomInput = forwardRef(({ value, onClick }, ref) => {
  //...codes
  return (
    <InputButton onClick={onClick} ref={ref}>
      {value === ''
        ? checkInDate.length === 0 && checkOutDate.length === 0
          ? '날짜를 입력해주세요.'
          : checkInDate + ' - ' + checkOutDate
        : value + ' | ' + days + '박'}
    </InputButton>
  );
});

custom hook을 통해 조금 더 정확한 관심사의 분리

인원별 필터링을 구현할 때 인원을 조절하는 훅을 만들어 인원수를 조절하는 기능만 담당하도록 구현하였다. 그럼 인원수를 조절하는 방식이나 값을 변경해야 하는 경우가생기면 해당 훅에서만 변경해주면 된다.

👇 /src/pages/RoomList/DropDown/People.js

const useCounter = () => {
  const [searchParams] = useSearchParams();
  const [quantity, setQuantity] = useState(
    searchParams.getAll('numberOfGuests').length === 0
      ? 0
      : searchParams.getAll('numberOfGuests')
  );

  const plusQuantity = () => {
    setQuantity(quantity > 9 ? 10 : quantity + 1);
  };

  const minusQuantity = () => {
    setQuantity(quantity < 1 ? 0 : quantity - 1);
  };

  return { quantity, plusQuantity, minusQuantity };
};

ㄴ💡 더 자세한 코드들이 궁금하시다면?

• github repository 바로가기

🥲 부족했던 점(Leaked)

상태관리의 부재

• 물론 엄청난 props drillling은 발생하지 않았지만 날짜를 관리할 때 props로 내려주는게 아닌 전역상태관리 라이브러리를 썼으면 어땠을까하는 아쉬움이 들기도 한다.

데드라인에 쫓기기

• 이건 사실 모든일에 마찬가지일 것이다. 데드라인에 쫓겨 기능을 구현하는데에만 급급했었다.
• 물론 모든 코드는 작성하는 순간 레거시가 되버린다.
• 그렇지만 클린코드를 작성해야한다고 계속 신경을 쓰고 머릿속에 있던 걸 바로 치지말고 한번 더 생각해보고 치는 습관을 들이자.

🙏 바라는 점(Longed for)

조금 더 사용자의 입장에서 생각해보자. 사용자는 내가 코드를 어떻게 치는지, 클린코드인지 관심도 없고 알 수도 없다. 그냥 UI가 직관적이고 편리하고 좋으면 끝인거다. 사용자 입장에서 이 페이지에 이렇게하면 더 편리할까?라고 생각을 해보자.

🥰 좋았던 점(Liked)

우리 팀원 분위기가 너무 좋았다.... 진짜 여기서 2달전에 만났던 사람들 맞나 싶을정도로 프로젝트 하는동안 같이 울고 웃었던 기억들이 많다..! 나의 리드하에 팀원들의 코로나 격리로 원격으로 소통하고 애자일 스크럼에 맞게 1주단위의 Sprint로 팀 프로젝트를 진행했다. Notion을 통해 daily standup metting기록과 Plan을 계획했고 Trello를 통해 전반적인 스프린트 개발일정을 공유하여 진척도를 조절하였다.

Scrum Process 애자일방법론에 따라 Weekly Sprint로 총 2번의 Sprint를 진행하였다.

Planning Meeting 하나의 Sprint가 시작되는 매주 월요일마다 Trello를 사용하여 해당 Sprint때의 목표를 설정하였다. Daily Standup Meeting 아침 10시마다 전날의 개발진척도와 오늘의 목표, blocker들을 공유하였다. Retrospective Meeting 최종발표 날 두번의 Sprint동안의 KPT회고를 통한 회고를 진행하였다.

Gitbook

gitbook을 통해 백엔드와의 소통도 원만하게 진행되었다. 백엔드, 프론트엔드 페이지 담당자끼리 API Data 형식이나 무엇을 넘겨줄건지 고민하면서 미리 협의해두었다. 그럼에도 중간에 필요하거나 수정할 부분이 생기면 그때그때 소통하여 조율하여 개발을 진행하면서 큰 변화가 없이 진행할 수 있었다.

✏️ 배웠던 점(Learned)

탭 별 조건부 렌더링

리스트페이지에서 처음에는 브랜드를 클릭했을 경우 Brand 컴포넌트를 return하게끔 switch case로 구현했었다. 멘토님의 피드백으로 객체를 사용해서 클릭한 탭의 id를 저장해서 해당하는 id의 content로 등록되어있는 컴포넌트를 불러오게끔 조건부 렌더링을 리팩토링 하였다.

👇 ProductList.js

const TABS = [
    {
      id: 0,
      title: '브랜드',
      content: <Brand />,
    },
    {
      id: 1,
      title: '가격',
      content: <Price />,
    },
    {
      id: 2,
      title: '사이즈',
      content: <Size />,
    },
  ];

            <div className="left-filter">
              <ul className="filter-list">
                {TABS.map(filter => {
                  const isCurrent = currentTab === filter.id;
                  return (
                    <li key={filter.id}>
                      <button
                        onClick={() =>
                          setCurrentTab(isCurrent ? '' : filter.id)
                        }
                        className={isCurrent ? 'current' : ''}
                      >
                        {filter.title}
                      </button>
                    </li>
                  );
                })}
              </ul>
            </div>
          {TABS.find(({ id }) => id === currentTab)?.content}

• TAB객체를 활용하여 id, content를 매칭하여 조건부 렌더링 구현

• map을 돌려 title을 불러와 필터링 버튼을 생성하고 click시 현재 tab의 id값을 설정한다.
• 현재 tab의 id를 TAB객체에서 찾아 해당하는 id의 content인 컴포넌트를 불러온다.
• 옵셔널체이닝을 통해 TAB객체에서 현재 tab의 id가 없는 경우, 즉 tab이 다 닫혀있는 경우 content를 불러올 수 없기 때문에 예외처리를 해주었다.
• • 현재 열려있는 tab을 한번 더 click시 현재 tab의 id와 TAB객체의 id가 같은 지 판별하여 현재 tab의 id를 reset하여 toggle기능 구현

querystring

브랜드, 가격, 사이즈의 정보를 state에 저장하였더니 새로고침이나 재접속 시 체크한 필터값이 날아가는 이슈가 발생했다. 검색 결과 상태로 저장하지 않고 url에 저장하는 querystring으로 리팩토링 하였다 !

👇 Brand.js

const [searchParams, setSearchParams] = useSearchParams();

  //TODO: 브랜드 검색기능
  const searchBrand = e => {
    const filterBrand = BRAND.filter(brand =>
      brand.name.includes(e.target.value)
    );
    setFilterList(filterBrand);
  };

  //TODO: querystring 생성
  const prevQuery = searchParams.getAll('brandId');
  const handleCheckbox = e => {
    const { checked, value } = e.target;
    if (checked) {
      searchParams.append('brandId', value);
      setSearchParams(searchParams);
    } else {
      searchParams.delete('brandId');
      prevQuery
        .filter(query => query !== value)
        .forEach(query => searchParams.append('brandId', query));
      setSearchParams(searchParams);
    }
  };

• checkbox에 check가 되었으면 searchparams에 append()를 통해 추가한다.

• check가 해제되었으면 해당 param key의 value들을 모두 삭제하고 이전에 모든 value들을 담아놓은 prevQuery변수에서 e.target.value인 것들을 제외한 value들을 다시 searchparams에 담는다.

path parameter를 통한 동적라우팅

상세페이지를 하나씩 다 만들어야하나 고민하다가 동적라우팅을 알게 되었다!

👇 Product.js

    <li>
      <Link to={`/product-detail/${id}`}>
        <img src={imgurl} alt="상품이미지" />
        <div className="like" />
        <div className="info">
          <span className="brand">{brand}</span>
          <span className="name">{name}</span>
          <span className="price">{Number(price).toLocaleString()}</span>
          <span className="heart">
            <i className="fa-regular fa-heart" />
            <em>999+</em>
          </span>
        </div>
      </Link>
    </li>

👇 Router.js

    <BrowserRouter>
      <Nav />
      <Routes>
        <Route path="/" element={<Main />} />
        <Route path="/product-detail/:productId" element={<ProductDetail />} />
        <Route path="/product-list" element={<ProductList />} />
      </Routes>
      <Footer />
    </BrowserRouter>

• Router.js의 path prop에 :productId로 이름을 지정한다.

• 상품리스트페이지에서 어떠한 품목을 선택해도 상품 상세페이지로 이동하게된다.

💡 더 자세한 코드들이 궁금하시다면?

• github repository 바로가기

🥲 부족했던 점(Leaked)

첫 프로젝트였던만큼 부족한 점이 많을 수 밖에 없었던 것 같다.

기획의 부실

• 프로젝트를 본격적으로 들어가기 전 기획회의를 시작할 때 이것저것 하고 싶은게 너무 많았다. 이것만큼은 꼭 하자던 동기들의 옷 데이터를 수집하여 이미지를 대체하자는 기획빼고는 다른건 실행할 수 없었다...

프론트엔드끼리의 부실

• 컨벤션이 잘 지켜지지 못했다. 나만 잘한다고 되는게 아니었고 다른 페이지의 부분을 commit만으로 무엇을 진행했는지 파악하면 소스를 다 뒤집어까지 않았어도 될텐데..아쉽다.
• 결제 페이지를 해내지 못했다. 장바구니 기능이 발표 당일 새벽 끝마쳐지지 못해서 결제 페이지를 만들었지만 사용할 수 없었다.

백엔드끼리의 부실

• 백엔드 개발자 인원이 2명이었는데 한 명이 일신상의 이유(?)로 팀원 1명이 독박이 씌워져버린 상황이 되었다...그러한 상황은 오롯이 프론트엔드의 피해로까지 이어졌고 시간과 경험이 절대적으로 부족하였다..

*시간의 부실 !!!! * 역시 데드라인은 죽음뿐...버릴건 버리고 일정관리의 중요성을 느꼈다..

🙏 바라는 점(Longed for)

Trello 티켓을 세분화 하여 진행하기

• 페이지를 하나의 티켓으로 했더니 Done 카테고리에 위치해있는게 아무것도 없어서 성취감도 없고 진척도 파악에도 어려움을 겪었다. 한 페이지의 조금 더 세분화하여 진행해보자. 프론트엔드끼리 지식 및 인사이트 공유하기
• 그래도 우리 같은 프론트엔드 개발자끼리 사이트도 공유하고 이럴 땐 이런 기술을 사용하면 더 좋을 것 같다라는 PR리뷰도 적극적으로 해보자.

📌 느낀 점

코드를 지울 줄 아는 개발자가 되자..! 이번에 리팩토링을 하면서 다 지우고 처음부터 다시 짠 코드도 있었고 부분적으로 다시 수정한 코드도 있었다. 내가 짠 코드가 정답이 아니다. 물론 코드에 정답은 없다고는 하지만 내가 짠 코드에 고집을 부려서는 안된다. 리팩토링이던 협업 내에 컨벤션이 수정되었던 내 코드에 집착하지말고 과감히 지울 줄 아는 개발자가 되어야겠다고 생각했다.

개발이나 테스트 목적이 아닌 실제 사용자들을 대상으로 서비스하는 서버

1-1. 단일 서버

가장 단순하면서 기본적이고, 구축하기 간단한 서버구조 전체 서비스의 장애 발생 가능성 높음 서버 자원을 효율적으로 사용하기 어려움 보안성이 떨어짐 scale-out 확장 방식이 어려움

1-2. 애플리케이션과 데이터베이스 서버 분리 구조

애플리케이션과 데이터베이스를 각각의 서버로 구성 두 서버가 다른 자원을 사용 두개의 서버를 관리하므로 구성은 다소 복잡 애플리케이션과 DB서버 사이의 지연시간과 네트워크 보안고려

1-3. 서버 단위의 로드 밸런서

서버의 로드밸런서를 추가하여 부하분산시켜 트래픽 과부화를 방지

1-4. 서버 내 앱 단위의 로드 밸런서

서버 내 앱 단위의 로드밸런서가 추가된 구조 기존 애플리케이션 서버 안에 똑같은 애플리케이션을 여러 프로세스로 만들어 실행 하나의 서버에서 여러 요청을 동시에 처리 서버자원을 효율적으로 사용

2. 온프레미스

IT 서비스를 기업이 자체적으로 보유한 물리적인 서버에 직접 설치 및 운영 인프라를 물리적으로 직접 구축하여 운영 서비스에 필요한 시스템을 구축하기 위해 기업이 직접 하드웨어를 구입 필요한 자원을 예측하여 물리적인 구성을 설계하는데 예측과 실제가 달라 이로 인해 불필요한 비용이 발생할 수 있음

3. 클라우드 컴퓨팅

it 리소스를 인터넷을 통해 온디맨드로 제공하고 사용한 만큼만 비용을 지불하는 것

## 클라우드 컴퓨팅 특징

• 요청하는 즉시 인터넷을 통해 온디맨드로 컴퓨팅 자원을 제공
• 원하는 시간동안 원하는 만큼 컴퓨팅 자원을 사용가능
• scale-up, scale-out이 자유롭게 가능
• 서비스에 따라 리소스의 타입을 변경 또는 사이즈 변경을 손쉽게 컨트롤
• 다양한 리전을 통한 글로벌 확장이 용이
• downtime이 적은 고가용성을 보장

## 클라우드 컴퓨팅 유형

1. IaaS(서비스형 인프라스트럭쳐) 클라우드 컴퓨팅의 가장 기본적인 계층 ex) AWS Elastic Compute Cloud(EC2)
2. PaaS(서비스형 플랫폼) 여러 개발환경을 미리 구축하고 그것을 서비스 형태로 제공 ex) AWS Elastic Beanstalk, Heroku, Redhat OpenShift
3. SaaS(서비스형 소프트웨어) 기본적인 클라우드 인프라와 소프트웨어를 사용자에게 함께 제공 ex) Google Drice, iCloud, Slack

코드의 가독성과 유지보수성을 향상시켜 코드 퀄리티를 올리기 위해 컴포넌트 분리를 적용

• view와 로직을 분리

• state에 따라서 분리 가독성이 떨어지지 않는지 재사용 될 수 있는지에 초점!

2. 조건부렌더링 구현

import Brand from './Brand/Brand';
import Price from './Price/Price';

const TABS = [
    {
      id: 0,
      title: '브랜드',
      content: (
        <Brand
          setSelectedAllFilter={setSelectedFilter}
          selectedFilter={selectedBrand}
        />
      ),
    },
    {
      id: 1,
      title: '가격',
      content: (
        <Price
          setSelectedAllFilter={setSelectedFilter}
          selectedFilter={selectedPrice}
        />
      ),
    },
  ];

<div className="left-filter">
              <ul className="filter-list">
                {TABS.map(filter => {
                  const isCurrent = currentTab === filter.id;

                  return (
                    <li key={filter.id}>
                      <button
                        onClick={() =>
                          setCurrentTab(isCurrent ? '' : filter.id)
                        }
                        className={isCurrent ? 'current' : ''}
                      >
                        {filter.title}
                      </button>
                    </li>
                  );
                })}
              </ul>
            </div>
{TABS.find(({ id }) => id === currentTab)?.content}

1. 해당 버튼을 클릭했을 때 그것에 맞는 panel을 보여준다.
2. panel에 보여줄 화면을 컴포넌트화 시킨다.
3. 탭을 눌렀을 때 변경되는 currentId값에 따라 컴포넌트가 보여질 수 있도록 객체에 컴포넌트를 할당하고 객체가 조건문의 역할을 수행할 수 있도록 구현한다.

• 동일한 클라이언트가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료하여 연결을 끝내는 시점 동안에 들어오는 일련의 Request를 하나로 보고, 그 상태를 일정하게 유지하여 클라이언트와 웸 서버가 논리적으로 연결된 상태
• 서버는 session에 대한 정보를 저장하고 클라이언트에게는 session을 구분할 수 있는 id를 부여
• request를 보낼 때 해당 session id를 부여

Session의 장점

• sessionID자체에는 유의미한 개인정보를 담고 있지 않다.
• 서버에서 정보를 관리하기때문에 데이터 손상우려가 적다
• 서버에서 상태를 유지하고 있어 로그인 여부확인이 쉽다.

  Session의 단점

• 사용자 수가 증가할수록 서버에 부하가 증가한다.
• 서버의 양을 늘리면 관리가 어려워진다.
• 중복 로그인이 가능해진다.

2. Cookie

• 클라이언트의 컴퓨터에 저장되는 데이터 파일
• 이름, 값, 만료날짜, 시간, 경로정보 등으로 구성
• 도메인당 20개를 가질 수 있고 1개당 4kbyte 이하
• 클라이언트에서 서버에 http request에 저장된 cookie를 함께 전달

Cookie의 장점

• 서버의 자원을 사용하지 않는다.
• 쿠키도 만료기간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지

  Cookie의 단점

• 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약
• 웹 브라우저마다 지원 형태가 다름
• 사용자가 보안상의 문제로 거부할 경우 사용 불가능

3. Token

제한된 리소스에 대해 일정 기간 동안 접근할 수 있는 권한을 캡슐화 및 접근할 수 있는 리소스의 범위와 접근 가능한 기간을 통제

Token의 장점

• token을 클라이언트측에서 저장하여 서버의 메모리 부담이 적고 서버증량에 용이하다.
• 모바일과 브라우저의 멀티환경에서 사용이 용이하다.
• 만료 시간을 짧게 설정하여 안정성을 높일수 있다.

  Token의 단점

• 서버에서 사용자의 상태를 저장하고 있지 않기때문에 로그인 여부확인 등의 제재를 가하기가 어렵다.
• 사용자가 임의로 토큰을 수정하거나 변경하면 서버에서 확인이 어렵다.
• Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id의 길이보다 길어져 HTTP request 전송 데이터의 크기가 증가

💡 세션 대신 쿠키를 사용하는 이유

세션이 보안성이 더 높고 데이터 손상우려가 더 적지만 쿠키를 사용하는 이유는 세션은 어쨌든 서버에서 관리하기 때문에 서버 자원의 한계를 느낄 수 있고 속도가 느려질 수 있다. 따라서 세션과 쿠키의 적절한 사용으로 보안성과 속도 둘 다 효율적으로 사용해야한다.

• RESTful API 설계방법(uniform interface)
• 인스타그램 리액트 클론코딩
  • fetch함수를 통한 서버와의 통신

FEELING

• fetch를 통해 백엔드와의 통신을 처음 시도했다. json형태로 주고받았고 처음으로 RESTful API를 접해보니 신기했다. response로 토큰을 받았고 로컬 스토리지에 저장하려고 했는데 네트워크 패널을 보니까 {object object}형식으로 나왔다...이것도 JSON.stringify로 json화 시켜주었더니 제대로 찍혔다.

FINDING

• RESTful API 설계 원칙
  • URL, HTTP method, Status Code를 통해 인터페이스를 구현
• fetch()

FUTURE ACTION

• 피드 좋아요, 검색기능 구현

• 인스타그램 리액트 클론코딩

    - 피드 컴포넌트 분리
    - 피드 별 댓글 등록/삭제 기능 구현

FEELING

• 피드 별로 댓글이 다르게 달려야하는데 한개의 피드에 댓글을 등록하면 해당 피드에만 등록되어야하는데 모든 피드에 등록이 되어서 당황했다. 원인은 피드를 컴포넌트로 분리시켰더니 해결되었다. 휴우
• 댓글에 달고 index를 key값으로 받아 해당 index로 댓글 삭제 기능을 구현했다. 댓글 컴포넌트에 해당 함수를 props로 넘겨줬더니 댓글을 넣자마자 바로 삭제되었다. 원인은 함수를 불러올 때 해당 함수 내용을 실행되는 것이었고 고차함수를 통해서 해결했다. 함수를 호출 시 함수내용을 실행시키는 것이 아니고 해당 내용을 return시키게 끔 해주었다.

FINDING

• 고차함수
• 구조분해할당 값의 변수생성하기

FUTURE ACTION

• fetch를 통한 서버와의 통신

• 인스타그램 리액트 클론코딩
  • 상수 데이터로 footer section 수정
  • mock data로 피드 구현

FEELING

• footer부분을 상수 데이터로 footer의 리스트들을 정리해서 map으로 구현하는 쪽으로 수정했다. 확실히 map으로 돌리니까 수월하긴 했는데 그럼 모든 리스트들은 다 map을 돌리는게 효율적인가에 대한 의문이 들었다.
• 백엔드와의 통신하기 전 mock data를 만들어 미리 유저정보, 이미지들을 불러와서 피드를 구현했다. 데이터객체를 만들어서 fetch를 통해 response를 받아서 map으로 뿌려줬다. 피드는 만든 mock data의 수만큼 나오지만 모든 피드에 댓글이 동일하게 올라가는 이슈가 발생한다....흐음

FINDING

• fetch()
• mock data

FUTURE ACTION

• mock data를 활용하여 각 피드별로 댓글 구현하기
• refactoring

React에서 side effect를 편리하고 안전하게 발생시킬 수 있게 도와주는 hook

useEffect(콜백 함수, 의존성 배열)

• 콜백함수 : 특정한 side effect를 수행
• 의존성 배열 : 렌더링 시 useEffect를 실행할 조건

2. 의존성 배열에 따른 useEffect 발생

import { useEffect } from 'react'

// 사용법
useEffect(콜백 함수, 의존성 배열);

// 1번
useEffect(() => {
  // side effect
});

// 2번
useEffect(() => {
  // side effect
}, [value]);

// 3번
useEffect(() => {
  // side effect
}, [value1, value2]);

1. 의존성 배열이 전달되지 않았으므로 매 렌더링마다 side effect가 실행된다
   2. 첫 번째 렌더링 이후에 side effect를 실행하고 그 이후에는 value 값이 변했을 때만 실행한다.
   3. 첫 번째 렌더링 이후에 side effect를 실행하고 그 이후에는 value1, value2 중 하나라도 변하면 side effect를 실행한다.

3. 컴포넌트 렌더링에 따른 useEffect 렌더링 과정

1. 컴포넌트가 최초로 렌더링 -> mount
2. useEffect의 콜백함수 실행
3. 컴포넌트의 state, props가 업데이트 되었을 경우 리렌더링 발생 -> updated
4. useEffect의 의존성 배열 확인

• 의존성배열 값이 없는 경우 : 최초 렌더링 시에만 호출하므로 콜백함수가 실행되지 않는다.
• 의존성배열 값이 변경된 경우 : 콜백함수를 호출한다.
• 의존성배열 값이 변경되지 않은 경우 : 콜백함수 호출하지 않는다.

5. 컴포넌트 간 이동하거나 필요없으면 화면에서 사라짐 -> unmount

4. clean up

컴포넌트가 unmount 시에도 해당 콜백함수가 계속 실행되고 있다면 효율성이 떨어지기 때문에 clean up을 통해 종료시켜줘야한다.

useEffect(() => {
    // 콜백함수 실행
    // ...
    // clean up을 하는 함수를 return
    return;
})

clean up을 호출하는 경우

1. 다음 side effect를 발생시키기 전
2. 컴포넌트가 unmount 되었을 때

5. clean up 호출순서

import { useState, useEffect } from 'react'
import { useNavigate } from "react-router-dom";


const App = () => {
    const [count, setCount] = useState(0);
    const navigate = useNavigate();

    useEffect(() => {
    console.log("test1");                             // 1

    return () => {
      console.log("test2");                           // 2
    };
  }, [count]);

    console.log("test3");                               // 3

    return (
        <>
            <button onClick={()=>{setCount(count + 1)}}>숫자 증가</button>
            <button onClick={()=>{navigate('/main')}}>메인 페이지 이동</button>
        </>
    );
};

export default App;

App 컴포넌트가 마운트 된 순간부터 ‘숫자 증가’ 버튼을 한번 누르고 ‘메인 페이지 이동’ 버튼을 누를때 까지 console에 출력되는 메세지의 순서는?

1. 컴포넌트 최초 mount시 'test3' 'test1' 가 차례로 출력
2. '숫자 증가'버튼 클릭 시 setCount()에 의해 의존성 배열에 값인 count state가 변화했으므로 콜백 함수가 실행, 'test3' 'test1' 가 차례로 출력
3. '메인 페이지 이동'버튼 클릭 시 unmount되어 컴포넌트가 사라졌으므로 clean up을 호출하여 'test2'가 출력

• 인스타그램 리액트 클론코딩
  • 댓글 컴포넌트화
• 코드 카타
  • strs은 단어가 담긴 배열입니다. 공통된 시작 단어(prefix)를 반환해주세요. 예를 들어 strs = ['start', 'stair', 'step'] return은 'st'

FEELING

• 인스타그램 클론코딩 댓글창 부분을 컴포넌트화 시켰다. 댓글 컴포넌트를 하나 만들어서 부모가 되는 main.js에서 map으로 돌리는 <li> 들의 key값과, 실질적인 댓글 부분인 input의 값을 props로 넘겨주고 댓글 컴포넌트에서 한개의 <li>에 key값과 댓글 input값을 받아서 뿌려주는 형식이다. 이렇게 하니 자바스크립트로 createElement()를 활용해 하나하나 태그를 만들어서 했을 때보다 훨씬 간편하고 편리했고 리액트내에서도 관리하기가 수월했다.
• 코드카타 부분에서 공통으로 시작되는 단어를 for문을 활용해 각 index마다 확인해보고 같으면 반환할 단어변수에 넣어주면 될 것이라고 단순하게 생각했었는데 이게 단어마다 길이도 다르고 prefix가 없는 경우도 있어서 알고리즘 짜기가 생각보다 복잡해서 힘들었다.

FINDING

• map함수 적용 시 key값을 부여해야하는 이유

FUTURE ACTION

• 스토리 부분 및 메인 페이지의 컴포넌트화
• 실질적인 백엔드와의 통신

컴포넌트 내부에서 컴포넌트의 상태값 -> 해당 컴포넌트가 UI에 보여줄 정보를 결정할 때 사용할 수 있는 상태값

2. state 선언 및 적용

import React, { useState } from 'react';

  const [value, setValue] = useState({
    id: '',
    pw: '',
  });

  const saveUserValue = e => {
    const name = e.target.name;
    const targetValues = { ...value, [name]: e.target.value };
    setValue(targetValues);
  };

• useState()를 사용해서 state를 관리한다.
  • 첫번째 요소 : 동적으로 관리하고자 하는 상태값
  • 두번째 요소 : 상태값을 업데이트하는 함수
  • useState()에 인자는 state의 초기값

• 결국 value = { id: '', pw:'' } 이고 해당 객체에 변화를 주고 싶으면 setValue()로 관리하게 되는 것이다.
• saveUserValue() 함수 호출 시 spread문법으로 기존 value의 값들을 가져온 후 해당 value객체에 해당하는 키의 값을 setValue()를 통해서 e.target.value로 업데이트 시킨다.
• setState function으로 해당 state를 업데이트하지 않고 단순 할당으로는 바뀐 값을 기준으로 화면이 다시 그려지지 않는다. setState function을 통해 state의 값을 변경해야만 값의 업데이트와 리렌더링의 효과를 볼 수 있다.