이번에 포트폴리오의 필요성을 느껴 github page를 통해 배포하는 방법을 찾아 보고 서칭하고 성공한 내용을 담은 블로그다.!.! ㅎㅂㅎ

Github Setting

공식문서를 보면 아주 자세히 설명이 되어있다. 그치만 링크의 링크는 피곤하니까~

1. 우상단의 New 클릭 하여 새로운 레포 만들기
2. 레포 이름을 사용자깃허브아이디.github.io 로 생성!
3. 세팅 진입
4. code and automation에서 Pages클릭
5. Build and deployment에서 브랜치 설정 후 save클릭!

• 위 과정은 해당 브랜치에 변경사항이 푸시되면 자동으로 배포를 실행하게 자체적으로 내장되어있다.

이 과정을 모두 거치고 나면 main 브랜치의 index.html이 http://사용자깃허브아이디.github.io 에 배포된다. 참 쉽쥬~?

근데.. Next.js는 메인 디렉토리에 index.html이 없는걸요..ㅠ 그러면 뭐가 나와요?! 그럼 어쩌냐며는! 이제 다음 과정을 살펴보자

Nextjs Setting

프로젝트 생성은 공식문서를 참고해서 만들자 .

일단 기본적으로 지식을 가지고 가보자. Next.js는 서버에서 React의 JavaScript 코드를 실행하여 초기 HTML이 생성된다. 이 html을 우리는 배포해야한다. 그러기 위해서는 빌드, 빌드된 파일 배포 등의 과정을 거쳐야 우리가 원하는 화면이 노출될것이다!

그러니까 요약해보자면

빌드 -> 빌드된 파일 푸시 -> 자동배포

이렇게 과정을 거쳐야 한다는 것이다. 이 과정들을 좀 더 편하게 진행 하기 위해 gh-pages라는 라이브러리를 다운받아서 사용한다.

npm install gh-pages

그리고 package.json에 몇가지를 추가한다.

  "homepage": "https://사용자아이디.github.io/",
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "predeploy": "npm run build",
    "deploy": "touch out/.nojekyll && gh-pages -d out -t true",
    "start": "next start",
    "lint": "next lint"
  },

그리고 next.config.mjs도 수정한다.

/** @type {import('next').NextConfig} */

const nextConfig = {
  output: 'export',
  reactStrictMode: true,
  images: {
    unoptimized: true
  },
  trailingSlash: true,
};


export default nextConfig;

이렇게 수정후

npm run deploy

명령어를 실행하면 predeploy를 먼저 실행 후 deploy 명령어를 실행한다.

📍 deploy명령어를 살펴보자.

touch out/.nojekyll:

touch: 파일을 생성하는 Unix 명령어.
out/.nojekyll: 'out' 디렉토리에 '.nojekyll'이라는 빈 파일을 생성.
목적: GitHub Pages가 Jekyll을 사용하여 사이트를 처리하는 것을 방지, Next.js와 같은 프레임워크로 빌드된 사이트에서 필요


gh-pages -d out -t true:

gh-pages: gh-pages 라이브러리를 실행. gh-pages 브랜치가 없다면 브랜치 생성, 있다면 해당 브랜치 aiming
-d out: 'out' 디렉토리의 내용을 배포.일반적 Next.js의 빌드 출력 디렉토리.
-t true: 'dotfiles'(점으로 시작하는 숨김 파일)도 포함하여 배포. 이는 '.nojekyll' 파일을 배포에 포함시키기 위해 필요.

이런저런 과정을 거치고 나면 해당 레포지토리에 자동으로 gh-pages브랜치가 생성되고 build의 결과로 생긴 out폴더 안의 내용이 해당 브랜치로 푸시되어있다.

그리고 아까 main브랜치로 고정시켜놨던 깃허브 세팅 또한 gh-pages로 변경후 저장한다. 저장 이후 위 탭의 Actions를 누르면 배포되고있음을 확인 할 수 있다. 성공후 링크로 들어가면 성공적으로 배포되어 있는것을 확인 할 수 있다! 근데 아마 이상하게 npm run dev로 보는 페이지와는 다르게 css가 어딘가 없는것을 볼 수 있다. 그 세팅을 아래서 해보자!

postcss setting

프로젝트 생성시 생성된 postcss.config.js를 수정해보자! 해당 파일은 css 후처리기로 모던 css 기능을 사용하고 브라우서 호환성을 높인다.(처음에 .mjs파일로 생성했는데 클로드씨가 js로 바꾸라고 해서 일단 그렇게 진행했음..) 일단 npm install autoprefixer --save-dev ,

module.exports = {
  plugins: {
    tailwindcss: {},
    autoprefixer: {},
  },
};

이렇게 수정후 npm run deploy를 진행하면 css가 적용된 모습을 확인할 수 있다.

이번엔 저번 시리즈에 이어서 프리패칭 대해 공부한 내용을 정리해 보고자 한다!.!

PRE-FETCHING

일단 프리패칭이란? 단어 그대로 pre-fetch 선행으로 fetching을 해오는 것을 뜻한다. mdn문서의 정의를 가져와보면 더 이해가 쉽게 되는데

프리페치는 사용자가 가까운 미래에 탐색할 가능성이 '있는' 페이지에 대해 백그라운드에서 리소스를 추론적으로 가져오는 방식을 의미합니다.

정의대로라면 사용자가 가까운 미래에 탐색할 가능성이 있는 페이지를 알아야 하는거잖아? 알 수 있는 방법은 여러가지가 있는데 그 부분은 내가 말하려는 내용과 살짝 멀어지기 때문에 생략해야지! (GA 심기..등)

Link tag Prefetching

<link rel="prefetch" href="/images/large-image.jpg">
<link rel="dns-prefetch" href="https://example.com">
<link rel="preconnect" href="https://example.com">
<link rel="prerender" href="https://example.com/next-page">

link태그의 rel속성을 컨트롤 해서 원하는 href 리소스를 미리 가져와 캐시에 저장하는 방법이 있다. 속성은 여러가지가 있는데 간단하게 살펴보면..

1. prefetch : 특정 리소스 미리 요청
2. dns-prefetch : 도메인의 dns조회를 미리 수행하여 실제 요청 시 시간을 절약
3. preconnect : 서버와의 연결을 미리 설정
4. prerender : 특정 페이지를 백그라운드에서 미리 랜더링

React Router loader

위는 html의 link태그를 사용한 방법이지만 React의 경우는?

import { createBrowserRouter, RouterProvider } from 'react-router-dom';

const router = createBrowserRouter([
  {
    path: '/',
    element: <Root />,
    loader: rootLoader,
    children: [
      {
        path: 'about',
        element: <About />,
        loader: aboutLoader,
      },
    ],
  },
]);

function App() {
  return <RouterProvider router={router} />;
}

React Router의 loader기능을 사용하면 된다. react router의 공식 문서를 보면 이 방법은 해당 라우트의 컴포넌트가 랜더링 되기 전에 실행되는 함수를 정의할 수 있다.

React Router Link

// PrefetchLink.js
import React from 'react';
import { Link } from 'react-router-dom';

const PreFetchLink = ({ to, children, prefetch }) => {
  const prefetchComponent = () => {
    if (prefetch) {
      prefetch();
    }
  };

  return (
    <Link to={to} onMouseEnter={prefetchComponent} onFocus={prefetchComponent}>
      {children}
    </Link>
  );
};

export default PreFetchLink;

//App.js
import PreFetchLink from './components/PreFetchLink';
...
...
<PreFetchLink
   to="/"
   prefetch={() => import('./components/Home')}>
  Home
</PreFetchLink>

위 코드를 보면 실제로 해당 기능이 있는건 아니지만 Link컴포넌트에 onMouseEnter과 onFocus 기능을 사용해서 해당 children 에 마우스를 올리면 prefetch를 실행하여 해당 페이지를 미리 패칭해서 캐싱하게 된다.

위에 올린 세가지 방법 중 두번째 React Router loader의 경우 나머지 두가지 방법과 살짝 다르게 컴포넌트, 이미지, 리소스 등을 불러오는 것이 아닌 데이터를 미리 불러오는 방식으로 전통적인 프리패칭과는 좀 다르다.

정리

이렇게 시리즈 두번째로 prefetching을 알아봤다. 여타 다른 방법과 마찬가지로 prefetching 또한 너무 과도하게 사용하게 된다면 불필요한 페칭, 캐시가 늘어 성능에 영향을 끼칠 수 있기 때문에 위에서 말한 가까운 미래에 탐색할 가능성이 있는 페이지를 여러가지 방법을 통해 확인 후 꼭 필요한 컴포넌트 등에만 적용해야 할 것 같다!

마치며

정리를 마치며 개인적으로 드는 생각은 1편 코드스플리팅에 비해서는 당장 내(개발자)눈에 엄청난 차이가 보인다! 유저 퍼포먼스가 엄청나게 개선되겠다! 이런방법이 있구나! 라는 생각은 사실 좀 덜 들기는 했다. 물론 내가 지금까지 했던 프로젝트의 사이즈가 작아서 그런게 크겠지만 나중에 실무에 적용해 볼 수 있는 큰 프로젝트도 해보고 싶따! 끗!

어떤 개발자가 되고 싶나요?

에 대한 내용의 대화였다. 모든 개발자 분들이 그렇진 않았지만 본인의 확고한 기준과 생각을 가진 개발자 분들이 너무나 멋져보여서 나도 한번 생각해보게 된 계기가 되었다.

위 이미지는 부트캠프 초반에 멘토링 할 때 내가 썼던 내용이다.(아예 생각해본적이 없다는 증거..)

사실 그저 그냥 눈앞에 주어진 일만 수행하고 살아 왔기 때문에 나는 질문에 대한 답을 생각해본적이 진짜 첫 입사전에 말고는 없었다. 이번에 이력서도 쓰고 지원도 하고 부트캠프를 진행하면서 좀 그 질문에 대한 답을 진지하게 생각해 본 것 같다. 그래서 기록해두고 나중에 연차 찼을 때 또 보려고 기록해보려 한다. 🙄

"왜?"라는 질문에 답할 수 있는 개발자

내가 개발자에 큰 매력을 느꼈던 가장 큰 이유는 원인-해결-결과가 명확한게 아주 내스타일이였다..(이과-공대) 개발을 시작할 당시에 불확실한 입시준비를 하고 있었던 나였기 때문에 더욱 강하게 와닿았을 수 있을 것 같다. 이 내용과 약간 비슷하게 일을 하면서 느꼈던 되고싶은 개발자는 "왜?"에 대한 질문에 답할 수 있는 개발자가 되고 싶다는 점이였다. 의사 결정을 하던 어떤 업무를 하더라도 누군가 나의 결정에 대해 왜? 라고 물어보면 막힘없이 대답할 수 있는 개발자가 되고 싶다. 내가 어떤 결정을 할 때 내 스스로 의문을 품으면서 결정하는건 없었으면 한다...그러기 위해선? 끊임없이 공부해서 결정을 내릴때 명확한 근거를 가지고 결정을 내려야지! 라는 생각을 했다.

누군가에게 인사이트를 줄 수 있는 개발자

이번 부트캠프를 하면서 가장 인상깊었던 부분이 비슷한 연차의 개발자 분들이 본인이 같은 연차의 개발자 분들에게 하고 싶은 내용의 발표를 준비해와서 공유해주시는 부분들이였다. 기술적인 내용, 본인의 가치관 등에 대한 내용이였는데 "인사이트를 얻는다." 라는 문장에 대한 의미를 알게되었다. 사실 실무를 하면서 연차 높은 분들을 보면서 느꼈던 점은 오.. 역시 고연차 분들... 똑똑하셔 이거 뿐이였지만 비슷한 연차분들의 발표나 대화는 진짜 들으면서 벅찬? 느낌이 들었다. 나도 앞으로 개발자 분들이랑 대화를 나누면서 내 대화가 누군가에게 인사이트를 줄 수 있는 개발자가 되고싶다는 생각을 해보았다!

쓰고보니 죄다 공부해야 이룰 수 있는 목표들이다!....! 공부하자 나자신!!!

 "dependencies": {
    "chart.js": "^4.3.0",
    "react": "^18.2.0",
    "react-chartjs-2": "^5.2.0",
    "react-dom": "^18.2.0",
    "react-router-dom": "^6.11.2"
  },
  "devDependencies": {
    "@babel/core": "^7.22.1",
    "@babel/preset-env": "^7.22.4",
    "@babel/preset-react": "^7.22.3",
    "babel-loader": "^9.1.3",
    "css-loader": "^7.1.2",
    "css-minimizer-webpack-plugin": "^7.0.0",
    "html-webpack-plugin": "^5.5.0",
    "style-loader": "^4.0.0",
    "terser-webpack-plugin": "^5.3.10",
    "webpack": "^5.84.1",
    "webpack-bundle-analyzer": "^4.9.0",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^4.15.0"
  },

이렇게 dependencies와 devDependencies 두가지 항목으로 나눠져 있는걸 보곤 한다. 이 둘의 차이는 어떤걸까?

말 그대로 devdependencies는 개발 당시에만 사용하는 라이브러리들로 실제 production 빌드에는 포함되지 않는다. 테스트 도구나 트랜스파일러 등의 라이브러리등은 실제로 production에 사용되는 라이브러리가 아니기 때문에 dependencies 가 아닌 devdependencies 에 포함시켜야 한다. 이렇게 함으로써 얻는 이점은?

첫번째 빌드 최적화가 가능하다 빌드시 프로덕션 환경에서는 dependencies 에 명시된 패키지들만 설치된다. 그로 인해 빌드 크기가 줄어들고 설치시간이 단축된다. 두번째 package.json파일만 보고도 어떤 패키지가 dev환경에서 사용되는 패키지인지 한눈에 확인 할 수 있다.

devdependencies로 다운 받는 명령어를 잠깐 알아보자! (npm 쓴다고 가정)

npm install --save-dev [package-name] npm i -D [package-name] npm add -D [package-name]

이렇게 세가지 명령어를 통해 디펜던시 패키지로 인스톨이 가능하다! 무분별한 npm i 보다 좀 계획..?적으로 분리해서 패키지 관리를 해야겠다!

후기 한줄 요약 "아 나 진짜 무능하고 별거없는 개 쪼랩 개발자구나.."

일단 저는 비전공자, 20대후반의 나이에 항해99를 통해 개발자로 직무전환을 하게 되었습니다. 개발자를 선택한 이유는 솔직히 돈 잘번댔고(아님), 개발자는 모셔간댔고(아님), 연차가 무기라고 했어서(아님) 였기 때문이였습니다. 물론 셋 다 아니였지만 직무 자체도 워낙 저랑 잘 맞았고 개발하는게 그냥 너무 재밌어서 개발자로 취직하고 2년의 실무도 큰 일테기 없이 진행 해 왔습니다.

실무를 진행한 회사는 스타트업, 사수없음, 주니어 개발자들만 있음, 실사용 유저 거의 없음, 피쳐단위의 추가 개발만 계속 진행 의 대환장 파티였고 어느 순간 무리없이 개발을 진행하는 개발자로서의 제 자신에 대해 이게 맞나?그냥 이렇게 그저그런 개발자로 쭉 살면 되는걸까? 라는 고민이 어느 순간 들기 시작했습니다.

이런 저런 이유로 회사를 그만 두게 되었고 그만 둔 후 "내 고민들을 어디에 풀고 이야기 나누지..?나만 이런걸까? 어떻게 시작해야하지?" 라는 생각이 들어 개발자 커뮤니티에 대한 고민이 생겼고 부트캠프를 진행했던 항해 99에서 이런 내용의 광고 글을 거의 수료후 2년간 계속..지속적으로 뇌속에 각인을 해왔었고(가스라이팅 당한건가..?) 자연스럽게 항해 플러스 프론트엔드를 찾아보게 되었습니다. 사이트 들어가자마자 어? 이거 신청해보고싶다.. 했던 이유는 바로 커리큘럼과 네트워킹 때문이였습니다. 요즘 구직 글들을 보면 대부분의 회사에서 우대사항에 들어가있는 키워드들이 커리큘럼에 모두 들어가 있었기 때문에가 1빠따였고 비슷한 연차, 같은 직무, 돈을 낼만한 열정 이 세가지를 모두 갖춘 사람들이 모여서 공부를 한다는 사실이 또 한번 매력적이였습니다! (+12개월 무이자할부..굉장히 매력적)

아무튼 이러저러한 이유로 항해 플러스 2기가 시작되었고 기대했던 것 보다(기대가 크지 않았음..) 너무나 알차고 뿌듯한 10주를 보내게 되었습니다. 알찼던 이유를 생각해보면

1. 발제 자료들의 퀄리티 코치님들이 준비해주시는 발제 자료들과 발제 내용들이 굉장히 퀄리티 있고 충분히 발제 자료만으로도 공부할 수 있을정도로 꼼꼼했고 평생 소장하고 싶을 정도들의 퀄리티였습니다.
2. 비슷한 연차분들의 다양한 고민 저희 2기는 거의 대부분이 1~3년차 사이의 주니어 분들이셨는데 각자 처한 상황, 환경들에 대해 들을 수 있는 자리가 생겨 너무 좋았던것 같습니다. 중간에 수강생 분들이 본인들이 각자 정한 주제를 가지고 발표를 하는 세션이 있는데 그부분이 진짜 왕좋았어요... 막 인싸이트를 얻어가는 느낌? (+ 우리끼리 코드리뷰)
3. 루즈해지지 못하게 막는 과제 물론 발제날에 발제를 듣고 보는것도 너무 좋았지만 해당 발제와 맞는 내용의 과제를 가지고 일주일 동안 고민해보는게 또 하나의 오 나 열심히 했다! 하는 생각이 들게 하는 포인트? 였다고 생각해요. 물론 과제를 하고 통과함에 따라서 달라지는 뱃지 컬러..!도 한몫 하긴 했어요 ㅎㅎ
4. 세상 알찬 주1회 팀별 멘토링 팀별로 매주 1회씩 멘토님과 멘토링하는 그 한시간이 정말로 알찼던것 같아요. 궁금한 내용에 대해 답변해주시는것 또한 너무나 좋은 시간이였지만 멘토님들은 주로 어디서 인사이트를 얻고, 어떤식으로 실무 진행을 하시는지, 큰 회사들은 프로세스가 어떻게 되는지, 주니어들의 고민에 대해 어떻게 생각하시는지 등의 주니어 개발자로서의 궁금증을 듣고 함께 고민해주시고 공유해주시는게 정말 큰 힐링중에 하나였습니다. 공감해주시고 해결해 주시려고 하는게 그렇게 큰 힐링 포인트가 될줄은 몰랐지만... 최고의 힐링타임!
5. 운영진 분들의 빠른 피드백 수용 이 부분은 항해에 감동받았던 포인트 중 하나인데요 매주 발제가 끝날때 마다 해당 주차에 대한 피드백을 받아 매주 피드백을 수용하려고 노력하시는 모습이 좀 인상깊었습니다. 반영되지 않은 내용들도 있었지만 대부분은 반영 되었던 것 같아요.

뭐 죄다 좋은점 밖에 없냐?? 하면 이제 단점, 비추내용 읊어볼게요(단호).

1. 정착되지 않은 시스템 위에 5번과 일맥 상통하는 내용인데 어떤 분들에게는 이 부분이 큰 단점이 될 수 있을것 같아요. 이건 같이 계셨던 분이 하셨던 말인데 우리도 돈을 내고 들어왔는데 우리한테 피드백을 받아서 시스템이 계속 수정되고 변화되는건 아닌것 같다라는 분이 있어서 그말을 듣고나니 그건 그렇네.. 라는 생각이 들곤 했죠. 물론 프론트엔드 플러스 코스가 2기라서 그렇겠지만 만약 나는 딱 짜여진 시스템에서 공부하고싶어! 하면 고민을 좀 해보셔야 할 수도?
2. 절대적인 시간 부족 이건 단점이라기 보다는 만약 내가 회사에서 10주사이에 큰 프로젝트를 들어갈 일이 있다. 우리회사는 야근이 일상이다. 난 워라밸을 챙기고싶다. 하는 현직자 분들은 다시한번 잘 생각해 보시는게 맞을것 같아요. 저는 물론 백수라 10주동안 과제하고 발제 소화하는데 그렇게 큰 무리는 없었지만 같이 하시는 분들은 일과 병행하는 공부 시간, 과제 때문에 엄청 스트레스를 받으시더라구요 ㅠ.ㅜ 사실 내가 돈을 더 잘 벌기 위해 돈을 투자해서 공부하는거잖아요? 근데 그 돈만큼 내가 공부하지 못했다는 자괴감, 안타까움 이런게 있으신것 같더라구요. 충분히 이해가 가기도 하구요.
3. 이력서에 쓸 내용은 없음 사실 첨에 신청하면서 어 이거 해봤다. 정도로 이력서에 써야지? 하는 생각이 어느정도 있었는데 사실 10주동안 그 많은 내용을 보고 배웠다. 라고 이력서에 써 봤자 담당자 입장에서는 그래서 그걸 배워서 실무에서 퍼포먼스를 냈어? 라고 한다면 사실 대답할 말이 없을것 같아요. 이걸 배워서 실제 현직에서 써먹고 성과를 내야! 이력서에 쓸 수 있을만한 내용들입니다. 우린 주니어니까요!

이렇게 장점과 단점을 정리해 봤습니다. 여러분들의 결정에 어느정도 도움이 되었을까요..? 되었기를 바라면서..🫶

저는 항해 플러스 프론트엔드 2기 코스를 진행하면서 느꼈던 가장 큰 느낌은 위에 한줄 요약에서 말했듯이ㅋㅋ "아 나 진짜 무능하고 별거없는 개 쪼랩 개발자구나.." 사실 앞에서도 말했지만 2년정도 실무를 하면서 동료분들한테 기술적 질문을 받고 해결해 주기도 하고 실무도 기술적으로 큰 문제 없이 잘 쳐내고 하다보니 내가 꽤나 잘 해나가고 있구나! 나 다른데서도 왠만큼 하는 개발자겠지? 하는 오만방자한 생각을 하고 살았었답니다.. 그런데 와서 공부해보니 나는 그저 햄스터통에서 휠을 아주 잘 굴리는 갇힌 개발자였구나! 라는 사실로(팩트) 얻어 맞았답니다. 그치만 어느 순간 잊고 살았던 배움에 대한 즐거움, 동료 개발자들, 멘토님들에게 얻는 인싸이트들이 너무나 달콤해서 나도 앞으로 인싸이트를 줄 수 있는 개발자가 되어야지! 하는 다짐을 한번 해봤답니다.

10주, 등록비가 절대 적고 짧은 시간이 아니지만 그 돈, 그 시간을 투자하는 개발자 동료분들을 만나 이야기를 나누고 공부할 수 있다는건 진짜 엄청나게 큰 장점인것 같습니다! 혹시 주니어 부트캠프를 고민하고 계신 분들이라면 여기저기 잘 비교해보시고 제 글을 참고해서 본인에게 맞는 부트캠프를 하셨으면 좋겠어요. 주니어 부트 캠프 자체는 진짜 여유가 있다면 꼭 한번 해보시는걸 추천드리는 바 입니다!

할인코드

항플 신청 시 제가 제공해드린 할인코드를 사용하시면 20만원의 등록금을 할인 받으실 수 있습니다! 할인코드 : WE9tsU

항해 플러스 Lite 할인코드 : WE9tsU (10만원 등록금 할인)

일단은 위 컨닝페이퍼에서 코드스플리팅에 대해 먼저 공부하고 정리해 보고자 한다!

CODE SPLITTING

코드 스플리팅은 말 그대로 코드 쪼개기! 이다. 코드를 쪼갤 수 있는 방법들은 아래와 같다.

라우팅 기반의 코드 스플리팅

요지가 무언가 하니 프론트엔드는 html위에 js 스크립트를 그린다. 이런 페이지가 있다고 해보자. 하나의 js파일에 모든 home, dashboard, profile, settings, advanved feature을 몰아넣고 조건에 따라 화면만 변경된다고 하면 첫 화면을 그릴 때 js청크 파일의 크기가 엄청나게 커져 첫 로딩이 한세월 걸릴 것이다.

*하지만 만약 라우팅을 사용한다면? *

home, dashboard, profile, settings, advanved feature 모두 페이지 라우팅을 진행하게 된다면 해당 라우트 이동했을때에만 쪼개진 해당 컴포넌트의 js 청크가 로딩되게된다. 그렇게 된다면 기존에 모든 라우트가 한번에 로딩되게 하는것보다 유저의 청크 로딩 속도가 훨씬 빨라지게 되어 퍼포먼스 또한 향상이 될것이다!

컴포넌트 기반 스플리팅

큰 컴포넌트나 자주 사용되지 않는 컴포넌트를 별도로 분리하여 동적으로 로드할 수 있다. React.lazy()와 Suspense를 사용하면 이를 쉽게 구현할 수 있다.

// App.js
import React, { Suspense } from 'react';

// 동적으로 import할 컴포넌트를 React.lazy()
const HeavyComponent = React.lazy(() => import('./HeavyComponent'));

function App() {
  return (
    <div>
      <h1>내 앱</h1>
      <Suspense fallback={<div>로딩 중...</div>}>
        <HeavyComponent />
      </Suspense>
    </div>
  );
}

export default App;

// HeavyComponent.js
import React from 'react';

function HeavyComponent() {
  return <div>이것은 무거운 컴포넌트입니다.</div>;
}

export default HeavyComponent;

• 어디선가 많이 들어본 Suspense! 이 친구를 사용하면 예시처럼 무거운 컴포넌트가 로딩되는 중 유저에게 백지를 보여주는것이 아닌 fallback의 화면을 보여주게된다.
• React.lazy의 경우 동적으로 컴포넌트를 임포트하여 필요할 때만 로딩되게 한다.

이 두가지 설정으로 초기 번들 사이즈를 줄여 유저는 무거운 컴포넌트가 로드되는 동안 빈 화면이 아닌 로딩 화면을 보며 로딩 중임을 확인 할 수 있다.

실제 프로젝트에서는 모달, 복잡한 차트, 대시보드와 같은 무거운 컴포넌트등에 적용하게 되면 효과를 볼 수 있다!

이벤트 기반 스플리팅

이벤트 기반 스플리팅은 단어에서 알 수 있겠지만 특정 사용자 상호작용이나 이벤트가 발생했을 때만 필요한 코드를 동적으로 로드한다.

import React, { useState } from 'react';

function App() {
  const [showModal, setShowModal] = useState(false);
  const [ModalComponent, setModalComponent] = useState(null);

  const handleOpenModal = async () => {
    if (!ModalComponent) {
      // 동적으로 모달 컴포넌트를 import
      const { default: Component } = await import('./Modal');
      setModalComponent(() => Component);
    }
    setShowModal(true);
  };

  return (
    <div>
      <h1>이벤트 기반 코드 스플리팅 예제</h1>
      <button onClick={handleOpenModal}>모달 열기</button>
      {showModal && ModalComponent && <ModalComponent onClose={() => setShowModal(false)} />}
    </div>
  );
}

export default App;

// Modal.js
import React from 'react';

function Modal({ onClose }) {
  return (
    <div style={{ border: '1px solid black', padding: '20px' }}>
      <h2>모달 내용</h2>
      <p>이 모달은 동적으로 로드되었습니다.</p>
      <button onClick={onClose}>닫기</button>
    </div>
  );
}

export default Modal;

예시를 읽어보기만 해도 어떤 느낌인지 살짝은 감이온다! 예시를 보면 handleOpen이라는 유저의 이벤트 발생시 Component를 동적으로 불러와 state로 저장하고 그 때! 화면에 동적으로 불러온 컴포넌트를 노출시켜준다. (이 방법은 너무나 신기하자나?0ㅇ0) 이런 이벤트 기반 스플리팅은 위 두가지 스플리팅 방법과 마찬가지로 초기 로드 속도를 줄여 유저 퍼포먼스를 향상 시켜준다.

우선순위 기반 스플리팅

중요하지 않은 기능이나 콘텐츠는 초기 로드 후 지연 로딩으로 처리한다. 이는 초기 페이지 로드 시간을 줄이는 데 도움이 된다.

import React, { Suspense, lazy } from 'react';

// 높은 우선순위 컴포넌트는 일반적인 방식으로 import
import Header from './Header';
import MainContent from './MainContent';

// 낮은 우선순위 컴포넌트는 lazy로 import
const Footer = lazy(() => import('./Footer'));
const Sidebar = lazy(() => import('./Sidebar'));
const Comments = lazy(() => import('./Comments'));

function App() {
  return (
    <div>
      <Header />
      <MainContent />
      <Suspense fallback={<div>로딩 중...</div>}>
        <Footer />
      </Suspense>
      <Suspense fallback={<div>사이드바 로딩 중...</div>}>
        <Sidebar />
      </Suspense>
      <Suspense fallback={<div>댓글 로딩 중...</div>}>
        <Comments />
      </Suspense>
    </div>
  );
}

export default App;

// MainContent.js
import React, { useState, lazy, Suspense } from 'react';

const HeavyChart = lazy(() => {
  return new Promise(resolve => {
    // 3초 후에 컴포넌트 로드 (네트워크 지연 시뮬레이션)
    setTimeout(() => resolve(import('./HeavyChart')), 3000);
  });
});

function MainContent() {
  const [showChart, setShowChart] = useState(false);

  return (
    <div>
      <h1>메인 콘텐츠</h1>
      <p>이 부분은 즉시 로드됩니다.</p>
      <button onClick={() => setShowChart(true)}>차트 보기</button>
      {showChart && (
        <Suspense fallback={<div>차트 로딩 중...</div>}>
          <HeavyChart />
        </Suspense>
      )}
    </div>
  );
}

export default MainContent;

예시를 보면 세가지 포인트를 찾아낼 수 있다.

1. App컴포넌트에서 Header과 MainContent는 우선순위가 높게 간주되어 일반적인 방식으로 import, 나머지 Footer, Sidebar, Comments는 비교적 낮은 우선 순위로 간주되어 lazy import.
2. 각 지연 컴포넌트는 Suspense로 감싸서 대체 UI 노출
3. MainContent에서 무거운 컴포넌트인 HeavyChart 조건부 로딩

이런 방법을 사용하여 우선순위 기반 스플리팅을 사용 할 수 있다. 이 방법은 사용사자 어떤 화면을 먼저 확인하고 봐야 하는지에 대한 파악이 필요할 것 같다! 측정 방법은... 성능 측정 도구를 사용해야 한다고 한다.

벤더(써드파티 라이브러리) 스플리팅

애플리케이션 코드와 서드파티 라이브러리를 분리하여 캐싱 효율을 높이고 빌드 시간을 줄이는 기법이다.이 방법은 웹팩에 해당 설정을 넣어두면 웹팩이 스스로 라이브러리코드와 앱 코드로 분리하고 캐싱하게 된다. 사실 여기까지만 들으면 잘 감이 오지 않는다.

// 기존 방식의 결과
main.js (5MB) - 앱 코드 + React + 기타 라이브러리

<script src="main.js"></script>

// 벤더 스플리팅 적용 후 결과
main.js (1MB) - 앱 코드
vendor-react.js (2MB) - React 라이브러리
vendor-other.js (2MB) - 기타 라이브러리

<script src="vendor-react.js"></script>
<script src="vendor-other.js"></script>
<script src="main.js"></script>

위를 보면 약간 이해가 되는데 기존 방식으로 진행시 main.js에서 앱코드와 모든 라이브러리 코딩을 직렬적으로 수행하지만 벤더 스플리팅 적용시 앱코드와 분리되어 병렬적으로 로딩된다.

이 방법의 장점은

1. 필요 코드만 먼저 로드 가능하여 초기 로딩 속도가 증가될 수 있다.
2. 캐싱을 통해 첫 랜더 이후 빠른 로딩이 가능하다.

이렇게 두가지를 꼽을 수 있을것같다. 사용 방법은 차후에 정리해 보도록 해야겠다!

공통 모듈 스플리팅

여러 페이지나 컴포넌트에서 공통으로 사용되는 모듈을 별도의 청크로 분리하여 중복을 줄이고 캐싱을 개선한다. 이 방법 역시 마찬가지로 웹팩에게 해줘!! 하는 방법중에 하나다. 작동 방식을 살펴보자!

// webpack.config.js
const path = require('path');

module.exports = {
  entry: {
    main: './src/index.js',
    admin: './src/admin.js'
  },
  output: {
    filename: '[name].[contenthash].js',
    path: path.resolve(__dirname, 'dist'),
  },
  optimization: {
    splitChunks: {
      chunks: 'all',
      minSize: 0,
      cacheGroups: {
        common: {
          name: 'common',
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },
  },
};

위는 공통모듈 스플리팅을 위한 웹팩 설정 내용이다. 해당 파일을 해석해보면 entry로 설정한 main, admin 파일에서 splitChunks > cacheGroups을 통해 공통으로 임포트된 모듈을 자동으로 추출하여 common.js 파일을 만든다.

예를들어 main과 admin 파일이 아래와 같다고 가정하면.

// src/index.js
import { renderPage } from './common/utils';
import { fetchUserData } from './api';

async function renderUserPage() {
  const userData = await fetchUserData();
  renderPage('user', userData);
}

renderUserPage();

// src/admin.js
import { renderPage } from './common/utils';
import { fetchAdminData } from './api';

async function renderAdminPage() {
  const adminData = await fetchAdminData();
  renderPage('admin', adminData);
}

renderAdminPage();

웹팩은 자동으로 renderPage 를 common.js로 분리하여 로드시 불러올 수 있게 해준다. 즉 정리해보자면

// 기존 방식 (코드 스플리팅 없음)
main.js:
  - index.js 코드
  - renderPage 함수 코드 (중복)
  - fetchUserData 함수 코드

admin.js:
  - admin.js 코드
  - renderPage 함수 코드 (중복)
  - fetchAdminData 함수 코드

// 공통 모듈 스플리팅 적용 후
main.[hash].js:
  - index.js 고유 코드
  - fetchUserData 함수 코드
  - common.[hash].js 참조

admin.[hash].js:
  - admin.js 고유 코드
  - fetchAdminData 함수 코드
  - common.[hash].js 참조

common.[hash].js:
  - renderPage 함수 코드

이런식으로 분리되는 것이다. 이렇게 분리된 파일들은 다음과 같은 이점을 가지게 된다.

1. 중복코드 제거로 파일 다운로드 사이즈가 감소한다.
2. 공통코드의 캐싱을 통해 빠른 로드가 가능하다.

package.json 에서 패키지 관리하기

우리가 패키지json 파일을 보면

 "dependencies": {
    "chart.js": "^4.3.0",
    "react": "^18.2.0",
    "react-chartjs-2": "^5.2.0",
    "react-dom": "^18.2.0",
    "react-router-dom": "^6.11.2"
  },
  "devDependencies": {
    "@babel/core": "^7.22.1",
    "@babel/preset-env": "^7.22.4",
    "@babel/preset-react": "^7.22.3",
    "babel-loader": "^9.1.3",
    "css-loader": "^7.1.2",
    "css-minimizer-webpack-plugin": "^7.0.0",
    "html-webpack-plugin": "^5.5.0",
    "style-loader": "^4.0.0",
    "terser-webpack-plugin": "^5.3.10",
    "webpack": "^5.84.1",
    "webpack-bundle-analyzer": "^4.9.0",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^4.15.0"
  },

정리

여기까지 코드스플리팅을 할 수 있는 6가지 방법에 대해 공부하고 알아봤다! 내가 생각하기에 6가지 내용에서 공통적으로 강조하는 내용은

동적 로딩을 잘 활용할것!!! 그리고 웹팩을 통해 외부 라이브러리를 쪼개고 캐싱하자!!!

인것 같다. 물론 여러 참조한 문서들에서 공통적으로 했던 말은 무조건적인 코드 스플리팅은 좋지 않다는 얘기들이였다. 요청수 증가로 인한 트래픽상승 등의 문제가 생길 수 있기 때문에 회사의 인프라, 팀의 수준에 따라 진행해야 한다는 말이였다!

마치며

코드 스플리팅을 공부하면서 계속 혼잣말로 읊조린 단어가 있다. "와... 이런게있어? 우와.." 계속 중얼중얼 거리면서 공부했던것 같다. 모두 실무수준에서 적용이 가능한 내용인것 같아 꼭프로젝트에 적용시켜 보고 싶다는 생각을 했던 것 같다. 나머지 7가지 내용도 차차 공부해야겠다! 끝!

예시로 이런 컴포넌트가 있다고 할 때 수정, 삭제가 일어난다거나 +,-버튼을 누를 때 업데이트 이후 서버의 데이터를 가져오는 시점이 언제고 어떤식으로 반영해야할까? 라는 종류의 의문이 생겼다. 내가 생각했던 업데이트 시점,방법은 총 3가지였다.

1. 글쓴이가 글을 수정 후 수정하기를 누른 시점에 서버 데이터 pull
    a. response로 수정된 데이터 가져오기
    b. get을 한번 더 요청하기
2. 글쓴이가 글을 수정 후 수정하기를 눌렀을 때는 로컬에서 데이터를 조작해서 눈엔 수정한대로 보이게 하고 이후 페이지 재 진입 혹은 다른 트리거 상황에서 서버 데이터를 pull

2번의 경우 낙관적 업데이트에 해당하는데 여기서 낙관적 업데이트란?

낙관적 업데이트

낙관적 업데이트는 서버의 사용자 경험을 향상시키기 위해 등장한 개념이다. 기존 프론트엔드의 업데이트의 경우는 1번을 따른다.

사용자 동작 -> 서버응답 -> 들어온 응답으로 UI 업데이트

하지만 이 경우 서버 응답을 기다릴 때 서버 응답 지연 등으로 인한 사용자의 경험이 저하 될 수 있어 낙관적 업데이트라는 개념이 등장했다. 말 그대로 "사용자가 업데이트 눌렀으니까 무조건 업데이트 됐을거야!"라는 낙관적인 생각을 가지고 UI를 업데이트 하게 된다. 이렇게 되면 사용자는 본인이 업데이트한 내용을 지연 없이 바로 눈으로 확인 할 수 있게 되고, 그로 인해 사용자의 경험성 또한 상승한다. 약간 원영적사고..?

그럼 사용자 경험 향상을 위해서는 늘 르키비키적인 사고로 낙관적 업데이트를 해야하는건가? 하면 그건 아니다! 내가 보고 공부한 블로그에서 주신 예시가 가장 와닿아서 적어본다.

만약 e-commerce 관련 사이트라고 해보자! 사용자가 장바구니에 상품을 담고 결제를 클릭했을때 로딩창이 뜨고 결제가 진행되는것이 보통이다. 그런데 만약 여기서 낙관적 업데이트로 어! 결제 진행 된거야! 그니까 장바구니 비우자! 이렇게 되버리면 중간에 결제 취소등의 상황이 발생했을때 문제가 생길 가능성이 생긴다.

이처럼 서버 데이터와 UI의 일치성이 중요한 경우 르키비키적인 사고는 내려놓고 서버의 응답을 받아 진행해야한다.

그래서 어떤 시점에..?

사용자가 지연시간 없이 본인이 변경한 내용에 대해 즉각적으로 반영된게 보여야 한다? 그렇다면 르키비키적 사고로 낙관적 업데이트를 진행해보자!! 방법은 대강 말해보면

1. 처음 페이지 진입시 데이터를 가져온다.
2. 유저가 업데이트를 진행한다.
3. 서버에는 업데이트 내용을 전송하고 자체적으로 데이터 업데이트를 해서 UI 에 반영한다. (업데이트 되었을거야 ㅎㅎ ( ͡°ʖ ͡°))

물론 서버 업데이트 로직이 정확히 진행 되었을것이라는 자기 믿음이 필요하다 ㅋㅋㅋ 사실 2번이 "낙관적 업데이트" 라는 단어를 사용하는 업데이트 방식이 있다는건 첨 알았다. 이후 개발을 진행하면서 무조건적으로 서버 통신을 통해 ui 업데이트를 진행하지 않아도 된다면 낙관적 업데이트로 개발을 하여 사용자 경험을 개선해야 겠다!!

참고 블로그

💡 Batch : 일괄

React 개발자라면 batching 단어를 한번쯤은 들어봤으리라 생각한다! 나 같은 경우도 직접 겪으면서 아! batching 이라는게 일어나는구나~ 라고 알아본적이 있다. 하지만 이번에 batching 에 대해 깊게 학습해볼 기회가 생겼고 React 공식 깃허브에 있는 batch 에 대해 설명해둔 글을 해석 + 분석 해보려고 한다!

Batching 이란?

Batching은 여러개의 스테이트값들이 단 한번의 리랜더로 업데이트되는 현상을 말한다.

이렇게만 들으면 잘 이해가 되지 않으니 예시를 한번 살펴보자라

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);
  const [count2, setCount2] = useState(0)

  function handleClick() {
    setCount(c => c + 1); // 랜더 안됨
    setFlag(f => !f); // 랜더 안됨
    // 리액트는 배칭을 통해 마지막에 한번만 리랜더링 된다!
  }

  function handleClick2() {
  setCount(2); // 랜더 안됨
  setCount(5); // 랜더 안됨
  setCount(1); // 랜더 안됨
  // 리액트는 배칭을 통해 마지막에 한번만 리랜더링 된다!
  }

  console.log(count) // 0 -> 1 

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <button onClick={handleClick2}>Now</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

즉, state인 count와 flag의 값을 변경함에 따라 2번의 리랜더링이 일어나는 것이 아닌 handleClick이 끝나는 시점에 리랜더링이 일어나는 것을 뜻한다. 배칭의 장점은 불필요한 리랜더링은 줄임으로써 퍼포먼스를 올릴 수 있게 된다. 또한 배칭은 아직 끝나지 않은 작업에 대한 업데이트를 막음으로써 효율을 높일 수 있게된다. 공식 문서에서 재밌는 예시를 들어놨다._ 우리가 레스토랑 알바를 할 때 손님이 음식을 주문하면 첫번째 음식을 주문하자마자 주방으로 달려가 주문을 넣는것이 아닌 손님이 주문하는 모든 음식을 듣고 차후에 주방으로 가서 주문을 넣는 것 또한 효율 때문이 아니겠는가 하는 것이다._

React18 이전의 batch는 오직 브라우저 이벤트가 발생할 때만 자동적으로 batching 을 실행해 주었지만 18이후부터는 브라우저 이벤트 뿐만 아니라 promises, setTimeout, native event handlers 등의 다른 이벤트에서도 자동적으로 batching을 처리해준다!

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // 이때만 리랜더링
}

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // 이때만 리랜더링
}, 1000);

fetch(/*...*/).then(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // 이때만 리랜더링
})

elm.addEventListener('click', () => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // 이때만 리랜더링
});

난 싹 다 업데이트 하고 싶은데..?

batching을 하는것이 사실 이론상은 안전하지만 난 따로따로 업데이트 하고싶은데? 한다면? ReactDOM.flushSync() 를 사용하면 batching 처리를 하지 않고 state 변경이 될 때마다 업데이트를 할 수 있게 해준다.

import { flushSync } from 'react-dom'; 

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // 업데이트 됨
  flushSync(() => {
    setFlag(f => !f);
  });
  // 업데이트 됨
}

🤔 흠... 그럼 도대체 어떤식으로 동작하는거지?

한번 생각을 해보자! 어떻게 진행이 되는걸까?

1. 하나의 이벤트 내에서 여러번의 setState가 발생했을때 이것들을 한번에 처리하는 것을 Batching이라고 한다.
2. 이것을 구현하기 위해서는 어떻게 해야할까?
3. setState 가 여러번 발생 했을때 해당 이벤트를 어디에 모아 뒀다가 가장 마지막에 들어오는 애만 1frame 후에 실행되게 해야한다. 그럼 이건 후입선출 이니까 stack을 사용한다. stack에 넣어두고 1frame 후에 stack에서 pop을 해서 실행하면 된다.
4. 근데 그러면 이 과정들이 1frame 안에 일어났으며 한개의 스테이트값에 대한 변경만 발생했음을 알아야한다.
5. 그러면 해당 스테이트값에 대한 인덱스를 키로 가지면서 밸류값으로 스택을 가지고 있어야하지..? 그리고 처음 딱 이벤트가 발생하는 시점에 setTimeout을 걸어두고 1frame 후에 실행되게 해야한다.

이런 의식의 흐름에 이르렀다. 여기서 1frame 은 react에서 처리하는 타이밍을 인위적으로 표시하기 위해 설정한 조건이다. 실제 리액트는 훨씬 더 복잡하게 처리하겠지..?

공부하면서..

공부를 하면서 느낀점은 이런식의 동작이 자동으로 돌아가는 React에 대한 경외감과 재밌다!!! 는 생각이였다. 물론 왠만하면 자동적으로 batching 이 되기 때문에 의식하면서 사용하지 않아도 되겠지만 사용하면서 음~ 배칭됐겠네! 하는 일말의 생각을 하면서 사용할 수 있을것같다. 재밌따!

객체란 Key, value 를 짝으로 가지고 있는 구조로 여러개의 속성을 하나의 변수에 저장 할 수 있다.

_이번에 항플 프론트엔드 2주차 과제를 진행하면서 알게 된 점을 적어보자. _

원시 래퍼 객체

const a = '1'
const b = new String(1)
const c = 1
const d = new Number(1)
const e = true
const f = new Boolean(true)

console.log(a===b) //false
console.log(a==b) //true
console.log(c===d) //false
console.log(e===f) //false

여기서 a와 b, c와 d, e와 f 가 다른 이유는 뭘까? 이유는 new String,new Number,new Boolean 으로 만든 값은 원시값인 '1', 1 , true와는 다른 객체이기 때문이다. 찾아본 바에 따르면 원시 타입 값과 래퍼 객체는 서로 다르게 동작 할 수 있으므로 직접 래퍼 객체를 생성하는것은 권장되지 않는다고 합니다.

NodeList

document.body.innerHTML = `<div id="test"><span>1</span><span>2</span></div>`;
const spans = document.querySelectorAll('#test span');
console.log(spans); //NodeList(2) [span, span]

NodeList는 DOM API로 생성된 객체로 배열과 유사하지만 Array.isArray 에서는 false로 도출된다. 그렇기 때문에 만약 array 조건에서 걸릴것이라고 생각하면 안된다. NodeList 의 경우에는 target instanceof NodeList 조건을 사용해서 걸러줘야한다.! (array처럼 array의 동작을 하기는 한다)

큰 단위의 컴포넌트 분류

코드를 짜다보면 한 페이지 내에서의 사이즈가 점점 커지고 도대체 어떤 부분에서 컴포넌트 분리를 해야하지? 라는 생각이 드는 시점이 항상 있다. 가장 기본적으로 해당 페이지에서 컴포넌트 분리가 필요하다! 라는 생각이 든 순간 확인해봐야 하는 부분은 다음과 같다.

const [aaa] = useState()
const [bbb] = useState()
const [ccc] = useState()
const [ddd] = useState()

const [aaa] = useMemo()
const [bbb] = useMemo()
const [ccc] = useMemo()
const [ddd] = useMemo()

const handlerA = () => 
const handlerB = () => 
const handlerC = () => 
const handlerD = () => 
const handlerE = () => 

위의 코드를

const [aaa] = useState()
const [aaa] = useMemo()
const handlerA = () => 

const [bbb] = useState()
const [bbb] = useMemo()
const handlerB = () => 

const [ccc] = useState()
const [ccc] = useMemo()
const handlerC = () => 

const [ddd] = useState()
const [ddd] = useMemo()
const handlerD = () => 

const handlerE = () => 

이처럼 분류가 가능하다면 일단 컴포넌트 분리의 가능성이 있다고 생각하고 상하 관계를 따져가며, 의존관계를 따져가며 분리가 가능한지 고민해 볼 수 있다. 나같은 경우에는 보통 첫번째 코드처럼 함수는 함수대로 변수는 변수대로 응집시켜두며 코딩을 하는데 컴포넌트별로 결합해서 나타내 두는게 나중에 컴포넌트를 분리할 때는 훨씬 편할 것 같다는 생각을 했다.

컴포넌트의 성격에 따른 종류

1. UI 컴포넌트
2. UI + Domain
3. Domain
4. Layout
5. Section or Group

여기서 Domain 이란 서버에서 들어오는 데이터 형식 및 데이터를 뜻한다.

이 중 메인으로 다뤄볼 컴포넌트는 UI 컴포넌트와 UI + Domain 컴포넌트이다.

UI 컴포넌트

UI 컴포넌트는 우리가 흔히 아는 MUI, ANTD 등의 디자인이 입혀진 컴포넌트를 뜻한다. UI 컴포넌트는 우리가 직접 만들지 않아도 앞에서 언급했던 css 프레임 워크를 가지고도 편히 사용할 수 있다. 하지만 우리는 ui 만 보여주는 것이 아닌 도메인 또한 연결해서 사용해야 한다. 보통 ui 컴포넌트만 따로분리하는 경우는 예시를 보면 쉽게 파악이 가능하다.

위의 두 사진은 각각 당근마켓의 인기당근 알바와 인기 중고차 아이템의 UI다. 내가 처음에 딱 봤을때 두 UI가 비슷하기 때문에 "ItemCard라는 컴포넌트를 만들어 props로 알바 아이템인지,중고차 아이템인지 체크하는 부분을 넣어 구분하면 되겠다!" 라고 생각했었다. 이 생각이 UI중심의 컴포넌트를 생성하게 되는 것이다.

interface IItemBoxProps {
  isCar : Boolean;
  ...
}

const ItemBox = (props : IItemBoxProps) => {
...
return (
...
  {isCar? 
   <div>{props.item.price}만원</div>:
   <div>일급{props.item.price}</div>}
)
}

만약 앞으로 이 UI 가 변할일 없고 계속 이 형태를 유지한다고 하면 내가 만든 코드처럼 진행해도 자잘자잘한 부분만 변화하면서 사용하면 될 것 같지만 UI는 계속 뭔가 추가되고 삭제되고 하는 부분들이 분명히 있다. 해서 눈에보이는 UI 위주가 아닌 Domain 단위의 컴포넌트를 짜야한다.

UI + Domain 컴포넌트

만약 위의 예시인 당근마켓의 개발자라고 상상해보자(으히히) 디자인쪽에서 "이번에 당근마켓 알바 UI를 이렇게 변경해주세요!" 라고 요청이 들어왔다고 상상해보면 만약 위의 예시처럼 UI 위주의 컴포넌트를 짰을 때는 머리가 아주 아파질 것이다. 그도 그럴것이 중고차와 알바를 같은 UI로 묶었기 때문에 중고차는 원래 UI 그대로, 알바 UI는 변경 이렇게 처리를 해야하기 때문일 것이다. 하지만 만약 AlbaItemCard , CarItemCard 이렇게 따로 처리를 했다고 한다면? CarItemCard 는 그대로 두고 AlbaItemCard만 UI 를 변경하게 되면 되는것이다! 여기서 생각해 봐야 할 점은 컴포넌트 분리는 코드의 유지,보수를 쉽게하기 위함! 이라는 점이다. 그런 의미에서 UI 위주의 컴포넌트 분리 보다는 Domain 위주의 컴포넌트 분리가 부합하다고 본다..!

아주 흥미롭고 재밌어 ㅎ흫ㅎ

이 내용은 항해 플러스 프론트엔드 2기를 진행하며 테오 코치님에게 여쭤보고 답변받은 내용을 정리한 글 입니다 :)

💡 PureComponent란? 클래스 컴포넌트에서 사용되는 Component로 해당 컴포넌트로 넘어오는 props 혹은 내부의 state를 이전값과 비교하여 변경시 리랜더링 되게 해주는 컴포넌트.

💡 React.memo란? 고차컴포넌트(HOC)로 props 값을 memoizing하고 있다가 값이 변경되면 해당 HOC를 리랜더링 되게해주는 함수.

언뜻보면 비슷해 보이는 PureComponent 와 React.memo는 다음과 같은 차이가 있다.

클래스형 컴포넌트 vs 함수형 컴포넌트

PureComponent는 클래스형 컴포넌트에서 사용되며 사용 시 사용하려는 컴포넌트를 extend시켜 사용한다.

import {PureComponent} from 'React'

Class ExampleComponent extends PureComponent {
...
}

React.memo는 일반적으로 함수형 컴포넌트를 위한 HOC로 원하는 함수형 컴포넌트를 감싸서 사용한다.

const ExampleComponent=memo(({ crying }: TCryingProps) => {
  return <p data-testid='dog'>강아지 "{crying}"</p>;
});

props 비교, state 비교

PureComponent는 props, state를 모두 비교하여 하나라도 변경되면 리랜더링 된다. React.memo는 props 만 비교하여 이전과 다르면 리랜더링 된다.

PureComponent는 React.memo를 사용해서 class component에서 함수형 컴포넌트로 변환이 가능하다.

공식문서의 예시를 참조해보자.

import { PureComponent, useState } from 'react';

class Greeting extends PureComponent {
  render() {
    console.log("Greeting was rendered at", new Date().toLocaleTimeString());
    return <h3>Hello{this.props.name && ', '}{this.props.name}!</h3>;
  }
}

const Greeting = memo(function Greeting({ name }) {
  console.log("Greeting was rendered at", new Date().toLocaleTimeString());
  return <h3>Hello{name && ', '}{name}!</h3>;
});

위의 예시처럼 하면 변환을 할 수 있다.

실제 실무나 코드 짤 때 기억하고 있다가 불필요한 리랜더링이 일어날때 적용해봐야겠다.!.

💡 useRef는 렌더링에 필요하지 않은 값을 참조할 수 있는 React Hook입니다.(공식문서)

무지성 사용하던 Hook을 파악해보자;ㅅ;

useRef 사용

📍값 참조

useRef는 처음에 준 초기값을 current 프로퍼티로 ref객체를 반환한다. 한마디로 정보를 저장하고 읽을수 있게 해준다. 이렇게만 말하면 useState와 차이가 없게 느껴지겠지만 state 값이 변경되면 리랜더링을 촉발하여 변경된 값을 시각적으로 출력시켜준다. 하지만 useRef의 ref 값은 값이 변경되더라도 리랜더링을 촉발시키지 않아 리랜더로 변하지 않아야하는 값을 사용하기에 적절하다.

📍DOM 조작

useRef는 DOM의 노드를 조작할 수 있게 한다.

<input ref={inputRef}/>

위의 예시처럼 사용하게 되면 input의 node를 관리할 수 있게 된다. 여기서 노드 관리는 예시를 예로 들면 input의 속성 (focus, value...) 등을 관리, 사용할 수 있게 되는것을 말한다.

import { forwardRef, useRef } from 'react';

const MyInput = forwardRef((props, ref) => {
  return <input {...props} ref={ref} />;
});

export default function Form() {
  const inputRef = useRef(null);

  function handleClick() {
    inputRef.current.focus();
  }

  return (
    <>
      <MyInput ref={inputRef} />
      <button onClick={handleClick}>
        Focus the input
      </button>
    </>
  );
}

직접 useRef() 만들어 보기

useRef의 역할을 알았으니 useRef의 역할을 할 수 있는 커스텀 훅을 만들어보자!

그럼 음 일단 내가 만들 useMyRef는 해야할 역할이

1. 값을 할당 할 수 있어야함
2. 값이 변해도 리랜더링이 되면 안됨
3. dom을 조작할 수 있어야함
4. 원하는 대로 값 변경은 할 수 있어야함

import { useState } from 'react';

export function useMyRef<T>(initValue: T | null) {
  // ref를 저장할 state를 생성. { current: initValue}객체를 통해 current값이 변경되더라도 리랜더링 되지 않게 함
  const [ref, setRef] = useState<{ current: T | null }>(() => ({ current: initValue }));

  // setRef를 통해 ref의 값을 변경.
  const setRefValue = (value: T | null) => {
    setRef({ current: value });
  };

  return [ref, setRefValue];
}

위의 코드를 보면 위에서 만족해야 하는 역할중 값의 할당은 useState를 통해서 처음 initialValue를 설정해주고 state값을 객체로 설정하여 current의 값이 바뀌더라도 리랜더링이 일어나지 않게 설정하였으며 useRef 와 마찬가지로 dom제어 또한 가능하다. 추가로 setRef를 통해 ref값의 변경 또한 가능하게 해 두었다.

해당 글은 스파르타 코딩클럽의 TypeScript 문법 종합반 강의를 바탕으로 작성되었습니다.

동적 타입 언어 VS 정적 타입 언어

• 동적 타입 언어 → JavaScript
  • 동적 타입 언어는 프로그램 실행 시 변수 타입을 결정한다.
    • 즉, 오류가 있더라도 실행을 해봐야만 오류 확인이 가능하다 → 문제 야기 가능성이 큼
  • 객체의 성질을 수시로 변경할 수 있다.
    • ex) let a = '사람' ; a = 4 string → number
  • =인터프리터 언어 → 엔진(V8, SpiderMonkey)이 코드를 한줄 씩 실행 하면서 동적으로 해석
• 정적 타입 언어 → TypeScript
  • 정적 타입 언어는 컴파일 시에 변수 타입을 체크하고 오류를 발견한다. (VScode의 경우 입력과 동시에 오류 체크)
    • 즉, 실행 전 오류를 체크해준다.
  • =컴파일 언어 → 기계어로 변환이 필요 (ex) tsc)

TSC(Compiler)

• tsconfig.json
  1. target : 컴파일 옵션을 설정
     1. javascript 버전 변환 설정
  2. module : js 모듈 형식 지정
  3. outDir : js 저장 dir 설정
  4. sourceMap : 에러 위치 찾기 용이

ReadOnly

• 객체의 속성을 불변으로 지정

  • const랑 다른점? readonly 는 class 속성에서 지정할때 사용가능 const 는 class 속성에 없어

    class Person { 
    readonly name: string;
    readonly age: number;
    
    constructor(name: string, age: number) {
      this.name = name;
      this.age = age;
    }
    }
    
    const person = new Person('Spartan', 30);
    
    console.log(person.name);  // 출력: 'Spartan'
    console.log(person.age);   // 출력: 30
    
    person.name = 'Jane';  // 에러: 'name'은 readonly 속성이므로 다시 할당할 수 없어요!
    person.age = 25;       // 에러: 'age'은 readonly 속성이므로 다시 할당할 수 없어요!

any, unknown, union

• any 는 타입을 쓰는 이유가 사라지는 큰 원인… 왠만하면 사용하지 맛!
• unknown
  • 타입 단언(Type Assertion)을 통해 타입 보장하여 사용가능
    • ex)as string
• union
  • 여러 타입중 한가지를 가질 수 있을 때 사용
    • type StringOrNumber = string | number;

유틸리티 타입

• Partial

  • Person interface 안에있는 속성값 중 일부만 가져올 때 사용

    interface Person {
    name: string;
    age: number;
    }
    
    const updatePerson = (person: Person, fields: Partial<Person>): Person => {
    return { ...person, ...fields };
    };
    
    const person: Person = { name: "Spartan", age: 30 };
    const changedPerson = updatePerson(person, { age: 31 });

• Required

  • 필수로 있어야함.

    interface Person {
    name: string;
    age: number;
    address?: string; 
    }
    type RequiredPerson = Required<Person>; // address 또한 필수로 있어야함.

• ReadOnly

  • 읽기온리 = 완전한 불변 객체 취급

• Pick<T,K>

  • Person interface 에서 name, age속성만 선택해서 새로운 타입 생성

      interface Person {
        name: string;
        age: number;
        address: string;
      }
    
      type SubsetPerson = Pick<Person, "name" | "age">;
    
      const person: SubsetPerson = { name: "Spartan", age: 30 };

• Omit<T,K>

  • 타입 T에서 K 속성들만 제외한 새로운 타입 생성

      interface Person {
        name: string;
        age: number;
        address: string;
      }
    
      type SubsetPerson = Omit<Person, "address">;
    
      const person: SubsetPerson = { name: "Alice", age: 30 };

객체 지향형 프로그래밍

• 클래스 , 객체 ⇒ 붕어빵틀 , 붕어빵

class Person {
  name: string;
  age: number;

  constructor(name: string, age: number) { //생성자, 온리원,초기화
    this.name = name;
    this.age = age;
  }

  sayHello() {
    console.log(`안녕하세요! 제 이름은 ${this.name}이고, 나이는 ${this.age}살입니다.`);
  }
}

const person = new Person('Spartan', 30);
person.sayHello();

• 접근제한자
  • public
  • private
    • 클래스 내부에서만
  • protected

객체 지향 설계 원칙(SOLID)

• SRP(단일 책임 원칙) ⭐
  • 클래스는 하나의 책임만 가져야 한다.
  • ex) 유저 클래스를 정의 했다고 하면 해당 서비스 하위에는 유저와 관련된 액션만 해야한다.
• OCP(개방 폐쇄 원칙)
  • 확장엔 열려있고 수정엔 닫혀있고
  • 기존 코드 변경안하고 해당 코드 가져다가 확장해서 쓰라~
• LSP(리스코프 치환원칙)
  • 서브타입은 기반이되는 슈퍼타입을 대체할 수 있다.
  • 즉, 부모 클래스는 모든 자식클래스를 아우르는 클래스로 구성이 되어야 한다~
• ISP(인터페이스 분리 원칙)
  • 너무 넓은 범위의 인터페이스는 지양하자
  • 다른 인터페이스에 영향이 갈 수있으므로
• DIP(의존성 역전 원칙)
  • 상위 인터페이스에 의존해야한다.

Warning : Each Child in a list should have a unique "key" prop.

프론트엔드 개발자라면 누구나 한번씩은 보는 콘솔의 빨간 에러... 처음에는 콘솔에 빨간 글씨만 보여도 수정할려고 애를 쓰던 내가 어느순간 없어도 돌아 간다 라는 오만하고 도라이 같은 생각에 안주되어 해당 에러를 무시한지 오래되었다. 그런데 며칠전... 오랫만의 기술면접에

key값을 index로 주셨는데 왜 index 값으로 주셨는지 DOM의 개념과 함께 설명해 주실 수 있을까요?

라는 질문에 머리가 띵해져서 대답을 절고 난 후에 서칭을 해보기 시작했다.

공식문서

리액트 공식문서 설명

키는 각 배열 항목이 어떤 컴포넌트에 해당하는지를 React에게 알려줍니다. 이렇게 하면 React가 나중에 이를 맞춰볼 수 있습니다. 이는 배열 항목이 이동하거나(예: 정렬 때문에), 삽입되거나, 삭제될 수 있는 경우 중요해집니다. 잘 선택된 키는 React가 정확히 무슨 일이 일어났는지를 추론하고, DOM 트리에 올바른 업데이트를 할 수 있도록 도와줍니다.

해당 설명을 쉽게 풀어보면 key의 역할은 배열의 정렬, 삽입, 삭제, 업데이트등의 일을 수행할 때 React가 이러한 변경 사항을 정확하게 추론할 수 있게 하여, 효율적이고 올바르게 DOM 업데이트를 할 수 있게 해준다고 나와있는것을 확인 할 수 있다.

하지만 이 때 map 메쏘드자체에 있는 index 값을 키로 지정하는것이 옳은가? 하면 그건 또 리액트에서 key 값을 사용하는 이유에 반하는 일이 된다. 이유는 간단하다. React가 변경 사항을 정확하게 추론하지 못하기 때문이다!

만약 삽입, 삭제등의 동작이 발생했다고 생각해보자. map함수 자체의 index를 넣은 경우 arr의 길이가 변경되면 데이터의 index 값 또한 변화하게 되고 모든 item 들은 새로운 index 값을 부여받게 될 것이다. 그렇게 되면 arr 내의 모든 값들이 새로운 key값을 부여받아 모두 새로운 항목으로 보일것이고 그럼 모든 값들이 새로 랜더링이 되게 된다. 하지만 만약 항목 고유의 값을 부여하게 된다면 삽입, 삭제등의 동작이 발생하더라도 기존의(변경되지 않은) 데이터는 새로 랜더링 되지 않는다.

정리해보자면

key값은 해당 아이템을 나타내는 고유값이며 배열의 변경(삽입, 삭제 등) 시 어떤 값이 변경되었는지 React가 추론할 수 있는 키이다. 그러므로! map 함수의 index를 key값으로 사용 하는 것은 바람직하지 않다.!

이제 알았으니까 면접 다시보게해주세요... 완벽하게 대답할 수 있어요ㅠㅠㅠㅠㅠㅠㅠㅠㅠ

이 글의 발단은 이전에 써놨던 노션을 정리하던 도중 왜 저렇게 제목을 지은지 모르겠는 글에서 시작되었다.

내가 저렇게 충격받은 이유가 뭔가 하니... NextJs 개발 초기에 이것저것 찾아보던 도중 nextjs 를 검색하면 가장 많이 나오는 SSR 즉, 서버사이드 랜더링에 대해 공부하고 적용해보다가 react의 훅을 사용하려면 컴포넌트에 무조건 'use client'를 사용해야한다. 는 점에 의문이 생겼다.

"...? 엥? 서버사이드 랜더링의 장점이 데이터를 미리 html위에 뿌려주고 있기 때문에 검색엔진에 노출되기 쉽다그랬는데.. use client 를 사용하면 SSR의 장점이 없어지잖아..?? "

에서 뻗어 나갔고 이것저것 검색을 해 보던중 충격적인 사실을 알게되었다. 여태껏 데이터를 받아오면 해당 데이터를 useState로 받아서 화면에 뿌려주기만 했었던 나에겐 신선한 충격이 아닐수 없었던 것이다.

import axios from 'axios';
import Head from 'next/head';
import { useRouter } from 'next/router'
import { useEffect, useState } from 'react';
import { Loader } from 'semantic-ui-react';
import Item from '../../src/component/Item';

const Post = ({item}) => {


    return (
        <>
            <Head>
                <title>{item.name}</title>
                <meta name="description" content={item.description}></meta>
            </Head>
            {item && <Item item={item} />}
        </>
    );
};

export default Post;

export async function getServerSideProps(context){
    const id=context.params.id;
    const apiUrl=`http://makeup-api.herokuapp.com/api/v1/products/${id}.json`;
    const res=await axios.get(apiUrl);
    const data=res.data;

    return{
        props:{
            item:data,
        },        
    };
}

위 예시를 보면..! useState로 데이터를 받아 state값을 뿌려주는 것이 아닌 서버에서 내려온 데이터를 props로 그대로 뿌려주는것을 볼 수 있었다..!! 저렇게 서버데이터를 받아와야지만 서버사이드에서 랜더링 시에 검색 노출이 높아지는 거시다...!...! 0ㅇ0!!!!(나만 충격일수도..ㅜ.ㅜ)

나자식 어디가서 SEO 최적화를 높이기 위해서 NextJS 써봤다고 하지말어라!

참고자료

web.dev 블로그에 올라온 Array.prototype.with 에 대해 설명한 내용을 정리한 것입니다.

가끔 web.dev에 올라오는 기술 포스트들을 보면서 이해할 수 있는것들을 이해해 보려 하는데 올해 올라온 기술로그 중 Array.prototype.with 에 대해 기술해 둔 기술로그를 발견하여 내가 이해한 대로 정리해 보려한다.

Array.prototype.with(index, value)

는 Array를 복사하고 복사된 복사본의 index 에 있는 값을 value로 바꿔주는 역할을 한다.

const ages = [10, 15, 20, 25];

const newAges = ages.with(1, 16);
console.log(newAges); // [10, 16, 20, 25]
console.log(ages); // [10, 15, 20, 25] (unchanged)

기존에 위의 과정을 수행하려면

const ages = [10, 15, 20, 25];
const newAges = [...ages];

newAges.splice(1,1,16)
console.log(newAges); // [10, 16, 20, 25]
console.log(ages); // [10, 15, 20, 25] 

의 한 과정을 거쳤어야 했지만 with 를 사용하면서 복사, 변경의 과정을 한번에 처리 가능하게 되었다. 당장은 어떤 상황에서 써야 이득일지 모르겠지만 기억해 둔다면 언젠가 아! 이런 메쏘드가 있었지 하면서 사용 할 날이 오지 않을까 싶다!

1. 넘겨받은 api 문서 그대로 코드를 짠다.

2. 코드를 실행한다.

3. 에러가 발생한다. 혹은 원하는 데이터가 넘어오지 않는다.

4. 백엔드 개발자님을 호출한다. ("이거 안돼욧! 봐주세여!! 뿌엥")

이러면 안됩니다..! 그거 들어보셨죠 구조를 요청할때는

"거기 빨간옷 입으신 여학생분! 지금당장 119에 전화해주세요!"

라고 해야 한다는 내용. 얘랑 비슷한 맥락으로 백엔드 개발자님에게 에러상황을 넘기려면 어떤 api에서 어떤 요청을 보냈을때 어떤 에러가 떴다! 를 전달드려야 백엔드 개발자분들이 파악하고 확인이 가능합니다.

그럼 어떻게 에러상황을 넘기냐! 이제 세세한 시나리오로 들어가 봅시다.

1. 개발자 도구의 네트워크 탭을 킨다.

1.1 원하는 페이지에서 해당 api 요청이 넘어갔다. -> 2로 이동

1.2 원하는 페이지에서 해당 api 요청이 발생하지 않았다. -> 3로 이동

2. 네트워크 탭의 해당 api를 클릭하여 Payload 탭을 클릭한다.

에러 status code를 확인한다. https://www.whatap.io/ko/blog/40/ 여기서 한번 어떤 모양의 오류인지 확인해보시면 좋을것같습니다.

일반적으로 저의 경우에는 404에러 -> 엔드포인트 잘못 입력 500에러 -> 백엔드쪽에서 개발 이후 문서 작성은 했지만 푸시를 안함(?)

2.1 백엔드 api 문서를 키고 내가 올바른 endpoint, 올바른 method(GET,POST,DELETE,PUT...), 올바른 방식(body에 request 값을 담는지, parameter로 넘기는지...),올바른 변수명(중요)으로 데이터를 요청하는지 다시한번 확인한다.

저같은 경우는 보통 2.1 에서 걸려서 수정,해결해왔습니다

2.2 그럼에도 불구하고 원하는 데이터가 넘어오지 않는다거나 에러가 발생한다.

위대하시고 멋지신 백엔드 개발자님... 제가 이런 api로 이런 요청을 이런 request 값으로 보냈는데 원하는 데이터가 들어오지 않아요.. 혹은 에러가 발생해요.. 시간이 나신다면 한번만 봐주시겠어요..?? (간절)

에러 발생시 response탭으로 에러 메세지가 들어오니 해당 메세지도 함께 보여드린다면 더 쉽게 찾으실거에요.

3. Console 탭을 켜 오류가 발생했는지 확인한다.

3.1 오류가 있다. -> 오류를 해결한다.

3.2 오류가 없다. -> 코드를 킨다.

코드에서 해당 api를 호출하는 위치에서 해당 호출 함수등이 라이프사이클 내에서 정확히 작동하는지 콘솔을 찍어가면서 확인한다.!

내 기준 이정도만 확인해도 이거안대여!! 하고 앗 제가 잘못했네요 (머쓱) 하는 상황은 거의 없었으니까 다들 최소 이부분은 확인하고 넘기도록 합시다!!

머리 한구석에서 아! memoization 이라고 기억하고 있는 기술이 있었던것 같은데.. 하면서 찾아본 React.memo 에 대해 이해한 내용을 적어보려한다!

Memoization

• 이전값을 메모리에 저장해 빠른 처리를 가능하게 하는 기술
• 결과를 캐싱하여 저장하고 있다가 다음 작업에 들어오는 결과값이 같다면 랜더링을 하지 않음

React에서 메모이제이션을 가능하게 해주는 방법은 React.memo,useCallback, useMemo가 있지만 그중에 React.memo를 알아봤다. - 이유는 useCallback, useMemo는 찾아보니 복잡한 계산 결과 등의 처리를 할 때 쓰인다고 나와있었는데 아무리생각해도 나는 그런 이유때문이 아닌것 같다 고 생각해서..? 이다.

React.memo

React.memo는 리액트에서 memoizing을 위해 사용되는 React HOC(Higher-order components)이다.

HOC(High Order Component)즉 고차 컴포넌트는 '컴포넌트 로직 재사용'을 위한 패턴입니다. 현재는 Hooks 를 사용한 로직 재사용이 더 일반적이지만 로직 재사용만을 아닌 컴포넌트 자체에서 조건부 랜더링을 하게 하기 위해서는 HOC가 더 적합하다.

React.memo는 부모컴포넌트에서 넘어온 props를 기억하고 있다가 부모컴포넌트가 리랜더링 된다고 해도 이전 props의 값과 같다면 해당 React.memo로 감싸진 자식 컴포넌트의 경우 다시 랜더링을 하지 않는다. (자기자신의 state값 변화시에는 리랜더링 O)

여기서 알아야할 점은! React.memo는 props 비교시 얕은 비교 를 진행한다. 원시 값의 경우는 같은 값을 갖는지 확인하고 참조값은 같은 주소 값을 가지고 있는 지 확인한다.결론적으로 memo는 props의 값이 원시값일 때만 유효하고 참조값일 때는 유효하지 않는다.

원시값 : 원시값은 문자열, 숫자, 불리언 등과 같이 값 자체가 비교 가능한 데이터. 예를 들어, string, number, boolean 등의 데이터

참조값 : 참조값은 객체나 배열과 같이 메모리 상에서 독립적인 객체로 존재하는 데이터. 예를 들어, object, array 등의 데이터

이는 리액트에서 객체를 비교할 때는 "얕은 비교"를 하기 때문이다

function sumFactory() {
  return (a, b) => a + b;
}

const sum1 = sumFactory();
const sum2 = sumFactory();

console.log(sum1 === sum2); // => false

위는 얕은 비교의 예시다. 주소(sum1, sum2)에 의한 비교지 각각의 내용물은 비교하지 않는다.

비교함수

보통 서버와 통신해서 axios 등을 통해 서버에서 가져온 값 랜더링 하는 경우 response로 들어오는 값은 보통 객체나 배열형태이다. 즉 참조값인 셈이다. 이럴때는 사용을 못하는걸까? 대답은 아니다! 가능하다!

React.memo의 두번째 인자로 비교함수를 싣어서 사용하면 해당 HOC 가 리랜더링 될 때마다 해당 비교함수를 통해서 이전 props 값과 비교해준다.

const areEqual = (prevProp, nextProp) => {
  return prevProp.obj.count === nextProp.obj.count;
};

const MyComponent = React.memo(({ obj }) => {
  // 렌더링 로직
}, areEqual);

React.memo에 대한 내용을 찾아보면서 항상 모든 블로그 등에 나오는 마지막 말이 있다. React.memo는 오직 성능 최적화를위해서만 사용된다. 랜더링 '방지'를 위해서 사용은 위험하다.는 말이였다. 사실 이 말은 아직 체감하거나 경험해본 바가 없어서 이해도 되지 않을 뿐더러 그럼 어떤상황에 써야 최적인가? 라는 의문이 들긴 한다만 너무 많이 쓰지 말라는 말이겠거니와.. 생각해본다!