https://typicode.github.io/husky/get-started.html

pnpm 기준

pnpm add --save-dev husky

다음 스크립트를 사용해 기본 셋팅을 간편하게 설정해줍니다.

pnpm exec husky init

스크립트 실행 후, .husky 파일에 pre-commit 스크립트가 생성되고, package.json에 이를 실행하는 prepare 명령어가 추가됩니다.

Hook 추가하기

husky는 hook 실행 전에 로컬 명령어를 실행할 수 있도록 해줍니다. 다음 파일들로부터 명령어를 읽습니다.

• $XDG_CONFIG_HOME/husky/init.sh
• ~/.config/husky/init.sh
• ~/.huskyrc (deprecated)

On Windows: C:\Users\yourusername.config\husky\init.sh

git hook 생략하기

single command

git hook을 생략하기 위해선, -n/--no-verify 옵션을 붙여줍니다.

git commit -m "..." -n # Skips Git hooks

해당 옵션 없이도 생략하도록 하기 위해 HUSKY=0을 설정해줍니다.

HUSKY=0 git ... # Temporarily disables all Git hooks
git ... # Hooks will run again

multiple command

여러 코멘드에서 생략하기 위해선, 시작 전 export HUSKY=0을 선언하고 git 명령어 입력 후 unset HUSKY을 통해 종료해줍니다.

export HUSKY=0 # Disables all Git hooks
git ...
git ...
unset HUSKY # Re-enables hooks

Global

컴퓨터에 기본 설정으로 hook을 사용하게 하지 않기 위해 ~/.config/husky/init.sh 파일에 다음과 같이 설정해줍니다.

# ~/.config/husky/init.sh
export HUSKY=0 # Husky won't install and won't run hooks on your machine

Commit 테스트

Commit을 테스트 하기 위해 실제 커밋이 동작하지 않도록 하는 방법도 있습니다. pre-commit 파일에 exit 1을 넣어주면, commit 명령어를 입력해도 실제 commit이 되지 않습니다.

# .husky/pre-commit

# Your WIP script
# ...

exit 1

git commit -m "testing pre-commit code"
# A commit will not be created

Commitlint 적용하기

https://commitlint.js.org/guides/getting-started.html

pnpm add --save-dev @commitlint/cli @commitlint/config-conventional 

configuration

echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js

husky를 이용해 hook 적용하기

echo "npx --no -- commitlint --edit \$1" > .husky/commit-msg

js로 기본 설치된 config 파일을 내부에서 ts를 사용하고 있는 경우, ts로 변경해주기

1. 임의의 컴포넌트 페이지에서 생성해 하나를 page에서 사용한다.

    // Test.tsx
    export const Test = () => {
      return <div>Test</div>;
    };
   
    // Page1.tsx
    ...
        <Test/>
    ...

2. next build 실행

3. 기존의 Test 컴포넌트 파일을 Test1로 변경하고, Test 파일을 새로 생성해 그 안에 Test 컴포넌트를 생성한다.

4. next build 실행

5. Text1의 Text를 사용하도록 변경한다 → next build 에러 (error msg : Text1의 Text가 unused)

6. Test1 삭제 후, Test의 Test를 사용하도록 한다 → lint 에러 안남 (맞음)
7. 다시 Test1 생성 후, Test1의 Test를 사용하도록 한다 → lint 에러 안남(..???) .next/cache/eslint 삭제하면..? 드디어 터짐 🤯

결론

파일 rename시, next lint 를 생활화합시다.

next에서는 빌드시 lint가 적용된 캐싱된 파일을 사용하기 때문에 별도로 lint가 실행되지 않는다.

https://nextjs.org/docs/basic-features/eslint

SVG로 꾸민 페이지가 safari에서 스크롤시 흰 배경이 나오면서 로딩이 생김

References

https://github.com/vercel/next.js/issues/34455

이미지에만 한정된 PR이라 enterprise 이슈에도 해당되는지 모르겠음.

찾아보니 safari에서 div 스크롤시 하얀배경(body의 배경)이 나오면서 로딩이 걸리는 이슈가 있는 듯함 → next + emotion 조합의 문제는 아닌건가

css hack 사용 → 실패

-webkit-transform: translate3d(0, 0, 0);
will-change : transform

원인

배경에 깔려있던 블러 이미지 때문. svg를 컴포넌트로 불러와 사용하도록 했으나 이게 레이아웃 계산에서 문제가 생기고 있었음 background로 불러와 사용하는 것이 좋음

// ❌
import EclipseIcon from "/__assets/icons/Eclipse.svg"
...
<EclipseIcon/>
...

// ⭕️
const WaitlistSection = styled(Section)`
  position: relative;
  overflow: hidden;
  background-color: ${COLORS.gray[900]};

  &::after {
    content: "";
    display: block;
    position: absolute;
    top: -50%;
    left: -20%;
    min-width: 900px;
    width: 100%;
    height: 600px;
    background: url("/__assets/icons/Eclipse.svg") no-repeat center center;
  }
`;

svg를 사용하는 다양한 방법 https://svgontheweb.com/ko/#implementation

2022년 3월 29일에 올라왔던 React v18.0을 읽고 해당 내용을 정리한 글입니다.번역본이 아니기 때문에 빠지거나 주관적인 내용이 있습니다.

What is Concurrent React?

React 18은 concurrent renderer 위에서 개발되었습니다.

• Concurrency : 하나의 기능이라기 보단, 동시에 여러 버전의 UI가 준비될 수 있는 매커니즘. 세부 실행 방식으로도 이해할 수 있음.

이를 구현하기 위해 priority queue나 multiple buffering같은 섬세한 기술들을 이용했지만, 개발자들이 이에 대해 이해하고 있을 필요는 없도록 설계되었습니다. 따라서 개발자들은 어떤 방식으로 concurrency가 이뤄질 지 고민하는 것보단, 유저가 어떤 유저 경험을 가지면 좋겠는지, 그 경험을 어떻게 전달할 것인지에 집중하며 개발하면 됩니다. 또한 Concurrency가 무엇인지만 이해하고 있으면 됩니다.

Concurrency에서 가장 중요한 포인트는 렌더링이 언제든 방해될 수 있다는 점입니다.

• 구 버전: uninterrupted, synchronous transaction
  • 기존에는 렌더링되는 동안 interaction이 불가
• React 18 : interrupted
  • 렌더링 중간에 방해받더라도, 동시에 UI가 나타남이 보장됨. 이게 가능하기 위해, 전체 트리가 계산이 끝날 때 까지 DOM mutation이 기다림.
  • 메인 쓰레드를 방해하지 않고, 새로운 스크린을 그릴 수 있음.
  • 큰 렌더링이 생기더라도 유저의 반응에 즉각적으로 응답할 수 있게됨.
  • Reusable state : 이전의 UI를 재사용하여 세션별로 렌더링을 쪼개 보여줄 수 있음.
    • 이를 구현하기 위한 <offscreen>이라는 컴포넌트 구현 예정
    • 2024.02 update <Activity>로 이름이 변경되고, 개발 우선순위가 낮아짐

Gradually Adopting Concurrent Feature

대부분의 이전 컴포넌트에서 별다른 변경없이도 "그냥 작동"은 하고 있지만, 어떤 컴포넌트들은 마이그레이션이 필요합니다. 전체적인 마이그레이션 방법은 기존 코드의 변경 없이 어플리케이션이 React 18에서 동작하도록 하는 것입니다. <StrictMode>를 사용하면 production에는 영향을 미치지 않고, 개발 중에 concurrent 관련 에러를 잡기 조금 수월할겁니다.

업그레이드를 하면 바로 concurrency 관련 기능들을 사용할 수 있습니다 (startTransition이나 useDefferredValuer같은). 장기적으로는concurrency를 직접적으로 사용하는 적용보다는 concurrent가 가능한 라이브러리나 프레임워크를 사용하길 기대하고 있습니다. (=maintainer들아 일해라)

Suspense in Data Frameworks

몇몇 라이브러리에서는 data fetching을 위한 Suspense를 사용할 수 있습니다. 즉각적인 data fetching에서 Suspense를 사용하는 것이 기술적으로는 가능하지만, 보편적인 방식으로는 권장하지 않습니다.

1. Reading the data data를 읽을 때마다 로딩상태에서 무엇을 보여줄 지 결정해야함

2. Spectify the loading state 한 페이지 내에 두 컴포넌트가 로딩 상태를 가질 때 이 두 컴포넌트의 로딩 상태를 합치고 싶은 경우 두 문제를 해결하기 위해 suspense를 사용

추후에는 특정 프레임워크가 아니더라도 suspense를 사용할 수 있도록 하는게 목표입니다. 가장 suspense가 잘 동작하는 방법은 본인의 어플리케이션 아키텍쳐에 깊에 통합되는 것입니다.

이전 버전에서는 suspense가 React.lazy와 함께 클라이언트에서 코드를 분리하는 역할로 사용되었지만, 코드를 기다리는 것 너머의 역할이 될 것입니다. (선언된 같은 suspense fallback에서 비동기적 오퍼레이션들을 다룰 수 있도록 - data fetching만을 위한게 아닌 비동기적인 이미지를 위한 fallback이라던가..)

(image from React 18 conf keynote)

Server Components is Still in Development

Server component는 서버와 클라이언트를 걸쳐 어플리케이션을 개발할 수 있도록 해주는 기능입니다.Concurrent rendering과 기술적으로 연관되어있지는 않지만, 함께 사용했을 때 더욱 잘 동작할 수 있도록 설계되었습니다. (현재 Next에서 app directory와 함께 사용 가능 - 사용 가능한 프레임워크들은 여기에 업데이트될 예정)

What' s New in React 18

New feature : Automatic Batching

기존 방식의 경우 React event handler 내부의 업데이트만 batch가 실행되고, Promises, setTimeout, native event handler 들은 리액트에서 기본적으로 배치를 지원하지 않았습니다.

하지만 데이터를 가져온 뒤에 상태를 업데이트하는 경우, (기본 event handler X가 아닌 경우) batch가 실행되지 않고

    function handleClick () {
    // (1) 렌더링
       fetchSth().then(() => {
    //    (2) 렌더링
          setCount(c => c+1);
          setFlag(f => !f);
       })
    }

callback에서는 (1) event가 종료된 이후에 (2)를 실행하기 때문에 (1)번과 (2)번 두 번의 렌더링이 발생됩니다. (본 글의 표현을 빌리자면 run "after" not "during")

반면 React 18에서는 어떤 이벤트에서 실행됐는지와 관계없이 항상 batch로 동작합니다. (Promises, setTimeout, native event handler 다 포함)

    function handleClick () {
       fetchSth().then(() => {
          setCount(c => c+1);
          setFlag(f => !f);
       })
   // 딱 끝나는 시점에서 렌더
    }

New feature: Transitions

transition은 급한(urgent) 업데이트와 급하지 않은(non-urgent)를 구분하기 위한 개념입니다.

• urgent transition : 타이핑, 클릭과 같은 유저 인터랙션 즉각 반영
  • UI가 즉시 바뀌지 않으면 에러로 간주됨.
• transition updates : 다른 뷰로 UI가 변경되는 것
  • 유저가 변경이 바로 이뤄질 것이라고 기대하지 않음

예를 들어, 필터버튼을 클릭했을 때,

• 필터 버튼이 변경됨 = urgent transition
• 필터된 내용이 로딩 이후 나타남 = transition updates

startTranstion API를 이용해 어떤 액션이 중요도를 가지는 지 알려줄 수 있습니다.

import { startTransition } from 'react';

// Urgent
setInputValue(input);


startTransition(() => {
  // Transition
  setSearchQuery(input);
});

startTransition에 들어간 업데이트는 다른 중요한 업데이트가 생기는 경우 언제든 우선순위가 밀려날 수 있습니다. 만약 transition이 유저에 의해 중단되면 React는 완료되지 않은 오래된 렌더링 작업을 버리고 최신 업데이트만 렌더링합니다.

• useTransition : transition을 시작하기 위한 hook. [isPending, startTransition]을 리턴
• startTransition : hook을 사용할 수 없을 때, transition을 시작하기 위한 method.

New Suspense Features

Suspense를 사용하면 컴포넌트 트리의 일부가 아직 표시될 준비가 되지 않은 경우 로딩 상태를 선언적으로 지정할 수 있습니다:

<Suspense fallback={<Spinner />}>
  <Comments />
</Suspense>

Suspense는 UI의 로딩상태를 일급 선언적 개념으로 만들어, 그 위에 고차원적인 기능을 구축할 수 있게 합니다. 추후 기능은 더 확장될 예정이며, transition과 함께 사용시 충분한 데이터를 받기 전까지 렌더링을 미뤄, 안좋은 로딩 상태가 보여지는 것을 막을 수 있게됩니다.

New Client and Server Rendering APIs

React DOM Client

react-dom/client에서 export되는 API들

• createRoot : render나 unmount를 위한 루트를 생성하는 메소드. ReactDOM.render 대신에 사용되며, 리액트 18의 새로운 기능들은 createRoot를 사용해야 적용됨
• hydrateRoot : 서버에서 렌더된 어플리케이션을 hydrate하기 위한 메소드. ReactDOM.hydrate 대신 사용되며, 리액트 18의 새로운 기능들은 hydrateRoot 사용해야 적용됨

두 메소드 모두 새 옵션인 렌더나 hydration 중 에러가 발생했다가 회복된 경우 로그에 안내하주는 onRecoverableError를 옵션으로 받습니다. 옛날 브라우저에서는 reportError나 console.error로 동작합니다.

React DOM Server

react-dom/server에서 export되는 API들

• renderToPipeableStream : Node 환경에서 스트리밍용
• renderToReadableStream : edge 환경에서 스트리밍용 (Deno, Cloudflare)

기존에 있던 renderToString도 동작하지만 권장되지는 않습니다.

New Strict Mode Behaviors

리액트에서 상태를 유지하며 세션별 UI를 더하거나 뺄 수 있도록 개발될 예정입니다.이게 동작하기 위해선 같은 컴포넌트 상태를 unmount하고 remount할 때 사용해야 합니다. 이에 컴포넌트는 탄력적으로 대응할 수 있어야합니다. 이 문제 해결을 위해 Strict Mode에서 모든 컴포넌트가 첫번째 렌더 이후 두번째로 이전 상태를 복구해 자동으로 unmount되고 remount 되는 옵션을 추가했습니다.

New hooks

useId

서버와 클라이언트에서 모두 유니크한 아이디를 만들어줄 수 있는 훅입니다. 서버와 클라이언트간 hydration 불일치를 해결해줍니다. 데이터 key로의 사용은 권장되지 않습니다.

useTransition

업데이트가 급하지 않은 상태임을 표시하는 훅입니다. 해당 훅이 사용되지 않는 업데이트는 모두 urgent update로 간주됩니다.

useDefferedValue

non-urgent 업데이트의 리렌더링을 미루는 훅입니다. 디바운싱과 비슷하지만, 고정된 딜레이 시간 없습니다.

useSyncExternalStore

외부 스토어가 스토어 업데이트를 강제로 동기화하여 동시 읽기를 지원할 수 있는 훅입니다. 외부 데이터를 얻을 때, useEffect를 사용하지 않아도 됩니다. 해당 코드는 application의 직접적인 사용보단, 라이브러리에서의 사용을 위해 개발되었습니다.

useInsertionEffect

CSS-in-js 라이브러리의 렌더링에서 스타일 주입의 성능 문제 해결을 위한 훅입니다. DOM mutaion 이후, layout effect가 새 layout을 읽기 전에 동작합니다. 이미 CSS-in-js를 구축해두었다면 사용을 권장하지 않습니다.

as-is : input 내부에서 enter 클릭시, 해당 폼의 submit이 동작 to-be : input 내부에서 enter 클릭시, 해당 폼의 submit이 동작하지 않았으면 좋겠음.

심지어 현재 폼의 submit 버튼은 폼 내부에 있지 않고 lnb에 위치해 폼에 대한 상태를 공유하고 있지 않고, form ID로만 연결되어 있어서 별도의 조작이 불가능한 상태였다.

// lnb
<button form="new-form">
    Submit
</button>

// form
<form id="new-form">
 ...
</form>

그래서 button이 분리된 상태에서 submit을 컨트롤 할 방법을 찾아보기로 했다.

Enter시 어떤 이벤트에 의해 submit이 실행되는가

enter는 키니깐 키 이벤트가 실행되겠지 ㅎㅎ → 아님 ❌

submit버튼에 onKeyPress, onKeyDown 이벤트가 실행되는 타이밍에 콘솔을 찍게 했지만 아무 동작도 하지 않았다.

놀랍게도 폼 내부에서 엔트키를 누르는 경우, onClick이벤트가 실행된다.

그러니 우리는 onClick 이벤트에서 유저가 버튼을 클릭한건지, 아니면 엔터키에 의한 클릭인지 구분해야한다는 의미이다.

onClick의 이벤트 객체엔 detail이라는 속성이 있더라

유저가 버튼을 직접 눌렀을 때와 엔터를 입력한 뒤의 각각 이벤트 객체를 뜯어보았다.

다른 곳에는 큰 차이가 없었는데, detail 속성이 각각 다르게 나타난 것을 확인 할 수 있었다.

엔터 입력시 : detail = 0 유저가 버튼 클릭시 : detail = 1

detail 속성은 클릭 이벤트에서는 유저가 클릭 한 수만큼 증가하고, mouseup/down 이벤트에서는 클릭수 + 1 의 값을 가진다. 그리고 이외의 이벤트에서는 0을 나타낸다.

그래서 유저가 직접 클릭한 경우에만 값이 1이 되고 (혹은 그 이상), 엔터를 통해 제출된 경우에는 0인 값이 나왔던 것이었다.

따라서 detail값이 0인 경우에는 제출을 막아 원하는 폼 형태를 만들 수 있었다.

<button 
    form="new-form"
    onClick={(ev) => {
    if (ev.detail === 0) {
      ev.preventDefault();
    }
  }}
>
 Submit
</button>

loading.js 파일은 React suspense를 이용해 의미있는 로딩화면을 보여주기 위해 사용되는 파일

Instant Loading States

즉각적으로 사용자에게 보여지는 fallback UI 페이지에서 데이터 fetching이 발생하는 경우, 해당 페이지의 같은 폴더 내 위치한 loading.js 를 fallback UI 로 보여준다. (Suspense가 없어도)

import type { Category } from '#/app/api/categories/category';
import { getBaseUrl } from '#/lib/getBaseUrl';
import { SkeletonCard } from '#/ui/skeleton-card';
import { notFound } from 'next/navigation';

export default async function Page({
  params,
}: {
  params: { categorySlug: string };
}) {

  // 🍀 해당 데이터가 fetching 되는 동안 가장 가까운 상위 계층에 위치한 loading을 보여줌
  const res = await fetch(
    // We intentionally delay the response to simulate a slow data
    // request that would benefit from `loading.js`
    `${getBaseUrl()}/api/categories?delay=1000&slug=${params.categorySlug}`,
    {
      // We intentionally disable Next.js Cache to better demo
      // `loading.js`
      cache: 'no-cache',
    },
  );

  if (!res.ok) {
    // Render the closest `error.js` Error Boundary
    throw new Error('Something went wrong!');
  }

  const category = (await res.json()) as Category;

  if (!category) {
    // Render the closest `not-found.js` Error Boundary
    notFound();
  }

  return (
    <div className="space-y-4">
      <h1 className="text-xl font-medium text-gray-400/80">{category.name}</h1>

      <div className="grid grid-cols-1 gap-6 lg:grid-cols-3">
        {Array.from({ length: category.count }).map((_, i) => (
          <SkeletonCard key={i} />
        ))}
      </div>
    </div>
  );
}

loading.js도 page.js와 마찬가지로 함께 위치한 layout으로 감싸진 채 보여진다.

Next.js의 네비게이션은 즉각적이며, 탈취 가능해 화면이 다 로딩되지 않더라도 다른 화면으로 이동 가능하다. 공유된 레이아웃(layout.js)은 내부 요소가 로딩될 동안 (완전히 렌더된 상태가 아니더라도) 인터랙션이 가능하다.

Streaming with suspense

next 13의 주요 기능 중 하나

UI의 렌더링된 단위를 점진적으로 렌더링하고 클라이언트에 점진적으로 스트리밍하는 기능으로, 데이터가 필요없는 부분은 먼저 보여주고, 데이터 fetchiing이 필요한 부분은 데이터를 받아오기 전까지 fallback ui를 보여준다.

loading.js 말고도 해당 컴포넌트에 커스컴 suspense boundary 설정 가능하다.

import { Suspense } from 'react'
import { PostFeed, Weather } from './Components'

export default function Posts() {
  return (
    <section>
      <Suspense fallback={<p>Loading feed...</p>}>
        <PostFeed />
      </Suspense>
      <Suspense fallback={<p>Loading weather...</p>}>
        <Weather />
      </Suspense>
    </section>
  )
}

What is streaming?

스트리밍에 대해 알기 위해선 SSR과 그 한계를 아는 것이 중요 SSR에서는 사용자가 페이지를 보고 상호작용하기 전에 완료해야하는 일련의 단계가 존재

1. 페이지에 필요한 데이터를 서버로 부터 받아옴
2. 서버는 페이지의 HTML을 렌더링함
3. HTML, CSS, JS가 클라이언트로 보내짐
4. HTML, CSS를 이용해 만들어진 유저와 상호작용하지 않는 UI들이 보여짐
5. React의 hydrate를 통해 인터랙션이 활성화됨.

이러한 단계는 순차적이고 차단적이므로 서버는 모든 데이터를 가져온 후에만 페이지의 HTML을 렌더링할 수 있다. 클라이언트에서는 페이지의 모든 컴포넌트에 대한 코드가 다운로드된 후에만 React가 UI에 dydrate할 수 있다.

Streaming은 페이지의 HTML을 작은 청크로 나눈 뒤, 점진적으로 서버에서 클라이언트로 보낸다. 페이지의 부분 요소들이 모든 데이터를 기다릴 필요 없이 더 빠르게 렌더될 수 있다. 중요도에 따라 먼저 보내지고 hydration도 먼저 시작할 수 있게 된다. 결과적으로 큰 데이터를 가져올 때 생기는 blocking이나, TTFB, FCP, TTI 의 blocking을 최소화할 수 있다.

Suspense의 장점

1. Streaming server rendering
2. Selective Hydration

SEO

Streaming UI 전에 generateMetadata 의 데이터를 먼저 받아온다. 이건 stream된 첫번째 응답이 <head> 태그임을 보장한다.

스트리밍은 서버에서 렌더되므로 SEO에 영향을 미치지 않는다.

아래의 링크를 통해 구글 웹 크롤링이 어떻게 이뤄질지 확인할 수 있다. https://search.google.com/test/mobile-friendly

기존 next의 dynamic route와 동일한 기능.

동적 세그먼트 : 요청 시 다운 받거나, 빌드 시 미리 렌더링됨

Convention

[folderName]

Example

export default function Page({ params }: { params: { slug: string } }) {
  return <div>My Post: {params.slug}</div>
}

페이지인 경우 params props로 dynamic route 값이 넘어옴. app/blog/[slug]/page.js -> params : {slug : 'a'}

generateStaticParams

generateStaticParams : 빌드 시점에 경로를 정적으로 생성 가능하도록 해주는 함수

export async function generateStaticParams() {
  const posts = await fetch('https://.../posts').then((res) => res.json())

  return posts.map((post) => ({
    slug: post.slug,
  }))
}

generateStaticParams 내부에서 fetch된 데이터는 다른 페이지의 generateStaticParams에서 데이터를 fetch 하더라도 한번만 데이터를 받아옴.

Catch-all segments

동적 세그먼트는 모든 하위 세그먼트를 가져오도록 확장 될 수 있음

Convention

[...folderName]

app/shop/[...slug]/page.js 에 /shop/a/b/c 로 접근시, param : {slug : [ 'a', 'b', 'c']}

Optional Catch-all segments

Convention

[[...folderName]]

기존 catch-all과의 차이점은 /shop 으로 접근시 param에 잡히는지의 여부

Catch-all segments 에서는 아무것도 잡히지 않지만, Optional Catch-all segments 에서는 {} 로 잡힌다.

App 디렉토리에서 일반적으로 중첩된 폴더는 URL 경로와 매핑된다. Route group을 이용하면 URL에 연결되지 않는 폴더를 만들 수 있다.

Convention

(folderName)

Example

1. 라우트를 URL에 영향 없이 구성하기

경로 그룹의 이름은 정리를 위한 것 외에는 특별한 의미가 없다. URL 경로에는 영향을 미치지 않는다.

따라서 다른 그룹 내에 있더라도, 같은 URL을 가리키는 경우가 발생해 오류가 생길 수 있다.

❌
app
 ㄴ (shirts)
     ㄴ about
         ㄴ layout.jsx
        ㄴ page.jsx   // /about
 ㄴ (pants)
      ㄴ about
         ㄴ layout.jsx
        ㄴ page.jsx   // /about

ex) (shirts)/about/page.js와 (pants)/about/page.js는 모두 /about 링크를 나타냄

2. 레이아웃에 특정 세그먼트 선택하고 싶다면, route group으로 묶어주기

각각의 폴더에 각자의 layout을 정할 수도 있다.

만약 도메인에 따라 다른 레이아웃을 가져가고 싶다면, route group을 이용해 서로 다른 레이아웃을 가지도록 할 수 있다.

• shirts 관련 페이지의 레이아웃에는 상의 목록이 나타나고, pants 관련 페이지에는 하의 목록이 나타나길 원하는 경우, (shirts)/layout.js 과 (pants)/layout.js 으로 분리해 설정 가능

최상위 위치에 (app/*) layout파일 없이 여러 루트 레이아웃을 사용하는 경우, 메인 페이지 파일은 경로그룹 중 하나에 정의되어야 한다.

❌
app
 ㄴ (shirts)
     ㄴ layout.jsx
 ㄴ (pants)
     ㄴ layout.jsx
 ㄴ page.jsx

 ✅
 app
 ㄴ (shirts)
     ㄴ layout.jsx
    ㄴ page.jsx    
 ㄴ (pants)
     ㄴ layout.jsx

여러 루트 레이아웃을 사용할 때, 레이아웃이 다른 페이지로 이동하는 경우 클라이언트 측 탐색이 아닌 (soft navigation X) 전체 페이지가 새로 로드된다.

Route로 이동하는 두가지 방법

1. Link 컴포넌트 사용
2. useRouter 훅 사용

<Link> 컴포넌트

https://nextjs.org/docs/app/api-reference/components/link 링크 컴포넌트는 리액트의 컴포넌트로 <a> 태그를 확장해 prefetching을 제공하고, 경로간 클라이언트에서의 이동을 지원한다. Next.js에서 경로를 이동하는 기본적인 방법

next/link를 import해서 사용하며 href prop으로 이동 경로를 받는다.

import Link from 'next/link'

export default function Page() {
  return <Link href="/dashboard">Dashboard</Link>
}

동적인 segment에 연결하기

import Link from 'next/link'

export default function PostList({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>
          {* use template literal *}
          <Link href={`/blog/${post.slug}`}>{post.title}</Link>
        </li>
      ))}
    </ul>
  )
}

활성화된 링크 확인하기

usePathname() 훅을 이용해 링크가 현재 활성화된 상태인지(지금 위치한 링크인지) 확인할 수 있다.

'use client'

import { usePathname } from 'next/navigation'
import { Link } from 'next/link'

export function Navigation({ navLinks }) {
  const pathname = usePathname()

  return (
    <>
      {navLinks.map((link) => {
        const isActive = pathname.startsWith(link.href)

        return (
          <Link
            className={isActive ? 'text-blue' : 'text-black'}
            href={link.href}
            key={link.name}
          >
            {link.name}
          </Link>
        )
      })}
    </>
  )
}

http://localhost:3000/snippets/search-params?sort=asc&page=2&perPage=100 링크에 있는 경우, pathname은 /snippets/search-params 을 리턴한다.

ID로 이동하기

<Link> 의 기본적인 동작은 변경되는 segment의 상단으로 스크롤 하는 것 href에 id가 명시되어 있다면, 해당 id가 위치한 곳으로 스크롤이 이동 스크롤이 상단으로 올라가는 걸 막고 싶다면, scroll props의 값을 false로 두고 hash(#)된 id 값 넣어주기

import Link from 'next/link'

export default function Page() {
  return <Link href="/dashboard#title" scroll={false}>Dashboard</Link>
}

useRouter() hook

useRouter 훅은 클라이언트 컴포넌트 내부에서 프로그래밍 방식으로 이동이 가능

'use client'

import { useRouter } from 'next/navigation'

export default function Page() {
  const router = useRouter()

  return (
    <button type="button" onClick={() => router.push('/dashboard')}>
      Dashboard
    </button>
  )
}

훅은 클라이언트단에서만 사용 가능하기 때문에, 가급적 link 컴포넌트 사용해 이동하는 것이 권장됨.

네비게이션 작동 방식

• 라우트 이동은 link 태그나 router.push()를 이용
• 라우터는 브라우저 주소창의 URL을 업데이트함
• 라우터는 클라이언트 캐시에서 변경되지 않은 segment의 재사용을 통해 불필요한 일을 줄이려고 함. (e.g. layout / partial rendering)
• soft navigation에서는 서버보다 캐시에서 세그먼트 데이터를 가져오지만, hard navigation에서는 서버로 부터 서버 컴포넌트를 받아옴.
  • soft navigation : 탐색 시 탐색 중인 경로에 동적 세그먼트가 포함되어 있지 않거나 현재 경로와 동일한 동적 매개변수가 있는 경우 Next.js는 소프트 탐색을 사용.
    • Navigating from /dashboard/team-red/* to /dashboard/team-red/* will be a soft navigation.
    • Navigating from /dashboard/team-red/* to /dashboard/team-blue/* will be a hard navigation.
• 생성된 경우 페이로드를 가져오는 동안 서버에서 로딩 UI가 표시됩니다.

클라이언트에서 렌더된 서버컴포넌트 캐싱하기

클라이언트측 캐시는 서버사이드의 Next.js HTTP cache와 다름

새 라우터는 서버컴포넌트의 렌더링된 결과를 갖는 클라이언트 사이드 내부 메모리 캐시를 가집니다. 이 캐시는 route segment에 따라 구분되며, 모든 레벨에서 캐시 만료(무효화)를 허용하고 동시 렌더링 간 일관성을 보장합니다.

user가 앱 내부를 돌아다니면 라우터는 이전 세그먼트와 미리 fetch된 segment 들을 보관합니다. → 서버에서 매번 받아올 필요 X

캐시 유효성 검사

Server Action은 데이터를 필요시에 재확인하기 위한 용도로 사용됨.

• path 별 : revalidatePath
• cache tag 별 : revalidateTag

근데 아직 알파 기능

prefetching

해당 페이지에 방문하기 전에 백단에서 미리 로드해놓는 방법 클라이언트 캐시에 캐싱된 값을 렌더링해준다.

Link로 연결된 페이지들은 기본적으로 prefetch

useRouter를 사용하는 경우 prefetch 함수 사용

Static and Dynamic Routes:

• 경로가 정적인 경우, 세그먼트에 대한 모든 서버 컴포넌트가 prefetch 됨
• 경로가 동적인 경우, 첫번째 공유 레이아웃부터 첫 loading.js 까지 prefetch.
  • 전체 경로를 동적으로 prefetch하는 데 드는 비용을 줄일 수 있고, 동적 경로에 대한 즉각적인 로딩 상태가 가능해짐

prefetching

• production에서만 가능
• <Link>태그에 prefetch={false} 값을 전달해 비활성화 가능

Soft Navigation

해당 세그먼트에 대한 데이터가 캐싱되어 있는 경우, 서버에서 다시 받아오는게 아니라 캐시를 사용

하나의 라우트에 해당하는 UI를 가진 파일

특징

• Page는 항상 라우트 트리의 끝단
• Pages의 파일 형식은 항상 .js , .jsx , .tsx
• Page.js 파일은 공개적으로 접근 가능한 라우트를 만드는데 필요함
• 기본적으로는 서버 컴포넌트이나, 클라이언트 컴포넌트도 가능
• 데이터 fetching 가능

Layouts

여러 페이지간 공유되는 UI를 가진 파일

네비게이션 상에서 layouts은

• 상태를 보존
• 상호작용을 유지하고
• 리렌더링하지 않음
• 하위폴더에서도 사용 가능

만약 layout.js 파일에서 layout을 default로 export한 경우, 컴포넌트는 반드시 children prop을 받아야 함. → 렌더링되는 동안 보여질 예정

export default function DashboardLayout({
  children, // will be a page or nested layout
}: {
  children: React.ReactNode
}) {
  return (
    <section>
      {/* Include shared UI here e.g. a header or sidebar */}
      <nav></nav>

      {children}
    </section>
  )
}

특징

• 가장 최상위 layout (Root layout)은 전역에 적용되며, html 과 body 를 포함해야함. (필수 컴포넌트)
• 최상위 레이아웃을 제외한 서브 레이아웃들은 optional. 한번 생성되면 위치한 폴더의 하위 페이지까지 적용됨
• Layout은 기본적으로 중첩되어 사용됨
• route 그룹을 사용해 공유 레이아웃 안밖에서 특정 route segment를 선택 할 수 있음.
• Layout도 기본적으로 서버 컴포넌트
• 데이터 fetching 가능
• 상위 레이아웃에서 하위 레이아웃으로 데이터 전달 불가능. 하지만 같은 데이터를 여러번 받아와도 리액트에서 중복되는 호출을 알아서 제거해주기 때문에 성능에 영향을 미치지 않음
• layout을 통해 현재 위치한 route segment에 접근 불가. 접근하기 위해선 client 컴포넌트의 useSelectedLayoutSegment 나 useSelectedLayoutSegments 사용
• layout 파일과 page 파일은 같은 폴더내에 위치 가능하며, 해당 Page를 layout이 감쌈

Root layout (필수)

export default function RootLayout({ children }: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  )
}

특징

• app 디렉토리는 반드시 하나의 root layout을 가지고 있어야 함.
• next.js가 자동적으로 html 과 body 를 생성해주지 않기 때문에, 반드시 root layout에 포함되어야 함
• 해당 html에 내장 SEO support 사용 가능
• route group을 이용해 여러 root layout 생성 가능
  • app 폴더에 바로 layout을 만들지 않더라도, app 폴더의 하위 폴더들에 html과 body를 포함한 폴더만의 root layout을 만들어 적용 가능
• pages directory → app directory로 마이그레이션시, 기존 _app.js 와 _document.js 를 layout 로 변경

Nested layout

상위 레이아웃은 하위 레이아웃 및 파일들을 children props 를 통해 감싸게 됨.

Templates

하위 layout이나 page를 감싼다는 점에서 layout과 비슷 경로 전체에서 상태를 유지하는 layout과 달리 template은 각 하위 항목에 대해 새 인스턴스 생성 → template을 공유하는 페이지간 이동시, 상태는 reset되고 effect는 재실행됨

사용 예시

• 입장/퇴장 애니메이션이 있는 라이브러리
• useEffect이나 useState 기반의 기능
• 프레임워크의 기본 동작을 바꾸는 경우, (ex, suspense는 처음 로드시에만 fallback을 보여주는데, 페이지 이동시마다 fallback을 보여줘야 하는 경우)

→ 위 상황이 아니라면 layout 사용이 권장됨.

export를 default로 하는 경우, 중첩된 segment 전역에 적용 → 그게 아니라면 self로 호출해야하나? - self로 호출시, unique key를 넘겨주어야 함.

<Layout>
  {/* Note that the template is given a unique key. */}
  <Template key={routeParam}>{children}</Template>
</Layout>

Modifying <head>

metadata 객체나 generateMetadata를 export해 layout 이나 page 에서 사용함으로써 적용 가능

import { Metadata } from 'next'

export const metadata: Metadata = {
  title: 'Next.js',
}

export default function Page() {
  return '...'
}

metadata를 <head>에 수동으로 입력할 필요 없이 Metadata api를 사용해 <head> 요소의 스트리밍 및 중복 제거와 같은 고급 요구사항을 자동으로 처리

Nextjs Documents [Routing Fundamentals] (https://nextjs.org/docs/app/building-your-application/routing) [Defining Route] (https://nextjs.org/docs/app/building-your-application/routing/defining-routes)

목표 : Routing에 필요한 개념들 이해하기

Routing Fundamentals

모든 application의 뼈대 == routing 한 어플리케이션에서 구조를 나타내기 위해 사용되는 링크 요소를 의미함.

url segment : 도메인 이후 /로 구분되는 부분 url path : 도메인 이후 모든 부분

Router of folders and files

next.js는 file based router

folder : router를 결정하기 위한 것 (page.js를 포함) file : UI를 만들기 위함 (special files)

Route segment

folder는 route segment로 사용됨

ex) www.dana.com이라는 도메인을 사용하는 프로젝트에 app 하위에 introduce 라는 폴더가 있는 경우(+ 해당 폴더에 page.js 존재), www.dana.com/introduce 에 접근 가능

Colocation

page.js / router.js 만 router로 사용 가능하기 때문에 같은 폴더 내 UI component 포함 가능

Server centric routing

client가 route map 다운로드 X link 컴포넌트와 같이 client-side인 경우, 유저가 새 링크로 이동 → 페이지를 reload X → 변경되는 컴포넌트(segment)만 render

유저가 접근한 페이지의 서버 컴포넌트 데이터를 segment별로 나뉜 client side cache에 저장

• 모든 수준에서 무효화를 허용
• 동시 렌더링에서 일관성을 보장

→ 이전에 사용된 segment의 재사용이 가능해 더 나은 성능을 갖게 된다는 의미

Partial rendering

(e.g. /dashboard/settings and /dashboard/analytics)

형제 라우터들이 서로 이동하는 경우, 레이아웃은 그대로 유지되고 부분적으로만 새로운 컴포넌트가 렌더링됨. (segment만 렌더링)

Advanced Rounting Patterns

Parallel routes

동시에 두개 이상의 페이지를 독립적으로 이동 가능한 하나의 뷰로 보여주는 방법

Intercepting routes

route를 가로채 다른 route의 내용을 보여주는 방법 현재 페이지가 중요해 해당 내용을 유지하기 위해 사용 ex) 하나의 업무를 수정하면서 다른 모든 업무를 확인해야할 때, 피드에서 사진을 확대할 때

Defining Route

Next.js는 file-system based router

Folder

폴더가 곧 route segment 하위 라우트를 만들기 위해선 해당 폴더 안에 하위 라우트 폴더를 만들면 됨.

page.js

page.js 파일은 공개적으로 접근 가능하도록 해줌. 해당 파일이 없는 폴더는 컴포넌트 저장소나 스타일시트, 이미지 등등 으로 활용가능

Creating UI

Special file convention은 각각의 route segment에 UI를 생성하기 위해 사용됨.

page.jsx는 하나의 라우트에 해당하는 UI를 보여주고, layout.jsx는 여러 라우트에 공유되는 UI를 보여줌

본 글은 https://nextjs.org/docs/getting-started/react-essentials 를 기반으로 작성되었습니다.

React Essentials

목표 : next 13을 본격적으로 공부하기 전에, 메인이 되는 서버 컴포넌트가 정확히 무엇인지 이해하기

다룰 내용

• 서버 컴포넌트 VS 클라이언트 컴포넌트
• 서버 컴포넌트를 언제 사용하면 좋을지
• 추천하는 사용 패턴

서버 컴포넌트

기존에는 default가 client 베이스였고, 페이지에 따라 SSR과 CSR을 나눌 수 있었음. 이제는 페이지별로 나누는게 아닌 컴포넌트별로 나눌 수 있게 됨.

기본 렌더링 방식은 SSR이고 내부는 Client 컴포넌트로 구성 가능 -> next.js의 서버 우선 접근 방식과 일치

왜 서버 컴포넌트를 사용해야 하는가

1. 개발자들이 서버 인프라를 더 잘 활용할 수 있게 해줌

   • 데이터를 가져오는 부분을 DB랑 더 가까운 서버로 옮김
   • JS 번들 크기에 영향을 미치던 대규모 종속성을 서버에 유지해 성능 개선
   • 서버 컴포넌트 사용시 PHP나 Ruby on Rails 처럼 사용하면서도, React의 장점(UI지향형 컴포넌트, 유연성 등)을 살릴 수 있음.

2. 초기 페이지의 로딩이 빠르고, Client-side 번들 사이즈가 줄어듦

   • 기본 client-side runtime 캐싱 가능하고 크기가 예측 가능
   • 그 외에 서버 컴포넌트로 사용되는 코드들은 크기게 영향을 주지 않음 (서버에서 처리되기 때문)

Next 13의 App directory에 있는 모든 컴포넌트는 Server component (page 뿐만 아니라 special files 및 같은 파일 내 존재하는 컴포넌트 포함)

• special files : error.tsx, layout.tsx ...
• next 13부터는 app 내에 페이지 뿐만 아니라 컴포넌트도 함께 위치시킬 수 있음 (app/main/page.tsx 와 app/main/input.tsx는 같은 main 폴더 내에 있지만, routing은 page만 가능)

클라이언트 컴포넌트

"use client"을 파일 맨 앞에 명시해 클라이언트 컴포넌트로 지정 가능 명시된 파일에 사용된 모든 모듈들은 client 번들에 포함됨.

언제 어떤 컴포넌트를 사용하는게 좋을까?

클라이언트에서 반드시 사용되어야하는 상황이 아니라면 서버 컴포넌트 권장

• event handler 사용 (onClick, onChange ...)
• useHook 사용시 (useState, useEffect ...)
• 위의 hook을 사용한 custom hook 사용시
• browser API 사용시
• React class component 사용시

사용 패턴

1. 클라이언트 컴포넌트를 DOM 트리의 가장 끝단으로 만들어 사용하기

2. 클라이언트 컴포넌트와 서버 컴포넌트 병합하기

React에서 렌더링하는 방식

• 클라이언트에 결과를 전송하기 전에 모든 서버 컴포넌트 렌더링
  • 이 때, 클라이언트 컴포넌트에 포함된 서버 컴포넌트도 포함
  • 클라이언트 컴포넌트 자체는 스킵됨
• 클라이언트에서 렌더링하면서, 서버에서 만들어진 결과물을 끼워 넣음

Next.js에서 렌더링하는 방식

• 일단 서버에서 서버 컴포넌트와 클라이언트 컴포넌트 모두 HTML로 변환(pre-render)

3. 클라이언트 컴포넌트 안에 서버 컴포넌트 넣기

'use client';

// This pattern will **not** work!
// You cannot import a Server Component into a Client Component.
import ExampleServerComponent from './example-server-component';

export default function ExampleClientComponent({
  children,
}: {
  children: React.ReactNode;
}) {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <ExampleServerComponent /> // ❌❌❌
    </>
  );
}

이렇게 클라이언트 컴포넌트 내부에 서버 컴포넌트를 바로 넣어두는 것은 지원하지 않는 패턴 앞서 언급했듯 이렇게 되면 서버컴포넌트를 클라이언트에서 한번 더 계산해 줘야하기 때문 (round trip)

해결 방법 : 클라이언트 컴포넌트에 서버 컴포넌트 Props로 전달하기

주로 children 형식으로 넘겨주는 방식이 사용됨. props 형태로 넘겨주는 이유는 클라이언트 컴포넌트 자체에서 들어오는 props가 무엇인지 알 필요가 없고 단지 이 props가 어디에 들어갈지 위치만 알고 있으면 되기 때문

'use client';

import { useState } from 'react';

export default function ExampleClientComponent({
  children,
}: {
  children: React.ReactNode;
}) {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      {children}
    </>
  );
}

4. 서버 컴포넌트에서 클라이언트 컴포넌트로 props 전달하기 (serialization)

서버에서 클라이언트로 전달되는 props들은 serialization 과정을 거침. 따라서 Props로 전달 시, functions, Date와 같은 형식은 전달 불가

Serialization? 네트워크나 스토리지에 전달되기 위한 파일 형태로 변환하는 것. JS에서는 Json.stringify()를 이용해 서버에 데이터를 보내는 방식을 의미한다. 따라서 deep copy가 불가능한 것들(unserializable)은 props로 보낼 수 없다.

https://developer.mozilla.org/en-US/docs/Glossary/Deep_copy

5. 클라이언트 컴포넌트 밖에서 Server-only code 유지하기

서버에서만 돌아가야 하는 코드가 클라이언트 컴포넌트에 침투하게 될 수 있음. 이를 막기 위해 server-only packages 사용

npm install server-only

설치 후, 서버에서만 사용되어야 하는 모듈에 import 해줌. 클라이언트 컴포넌트에서 해당 모듈 사용시, build-time error 발생

자매품 client-only도 있음

서버에서만 사용되는 케이스 next_public이 붙지 않은 환경 변수는 서버에서만 접근 가능하기 때문에, 서버에서 안전하게 key를 이용해서 데이터를 받아와야 하는 경우, 클라이언트에서 해당 모듈을 사용하면 안됨.

import 'server-only';
>
export async function getData() {
  const res = await fetch('https://external-service.com/data', {
    headers: {
      authorization: process.env.API_KEY,
    },
  });
>
  return res.json();
}

6. 외부 라이브러리 사용

대부분의 라이브러리들은 client 전용으로 만들어졌지만, "use client"가 표기되어 있지 않기 때문에, 서버 컴포넌트에서 호출 시 에러가 발생하게됨.

이를 막기 위해 외부 라이브러리의 컴포넌트를 별도의 컴포넌트로 다시 만들어서 사용해주어야 함.

"use client"

import { clientComponent } from "third-party-library"

export default clientComponent

Context

Server는 상태(state)를 갖지 않기 때문에 context는 클라이언트에서만 지원됨. 따라서 Provider도 위의 라이브러리처럼 client로 감싸서 사용해야함.

서버 컴포넌트간 데이터 공유가 필요한 경우, 데이터 자체를 공유하는게 아닌 DB에 대한 엑세스를 공유 (global singleton) 동일한 접근자를 가지고 각각의 컴포넌트에서 각자 데이터 호출

어처피 중복된 fetch 호출에 대해 next가 중복을 제거해 처리하기 때문에, 반복 호출에 대해 걱정할 필요가 없음.

하나씩 공부할 때마다 추가되는 Yarn 명령어 모음집

Yarn workspace foreach <명령어 이름>

사용 전, workspace tools를 사용해줘야 함 yarn plugin import workspace-tools

모든 workspace에 해당 command를 실행

옵션

• -p : 병렬로 실행
• -v : 어떤 workspace의 실행 결과인지 앞에 표시
• -t : 의존적인 workspace가 있는 경우, 선행 되어야하는 workspace가 종료된 후 실행

tldr; 유저가 어떤 path로 접근하는 경우, 특정 사이트로 옮겨주는 next 자체 기능 2가지 공식 문서 확인하기 : rewrites / redirect

공통점과 차이점

공통점

next.js에서는 rewrite와 redirect 기능을 제공한다. 두가지 모두 유저가 특정 path로 이동시 정해진 화면이 보이도록 한다.

차이점

두 설정의 다른 점은 rewrite는 유저가 입력한 url 그대로 유저에게 보여져 유저는 화면이 변경된지 모르는 반면, redirect는 정해진 path로 url이 바뀌게 된다.

예를 들어 유저가 www.minju.com/old 라는 path로 진입시, www.minju.com/new의 페이지를 보여주고 싶다면, rewrite는 주소창의 url이 www.minju.com/old 인채로 /new의 화면이 보여지고 redirect는 www.minju.com/old을 www.minju.com/new로 리다이렉트 해주어 유저가 입력한 값과 달리 www.minju.com/new가 주소창에 나타나게 된다.

설정 방법

설정 방법은 next.config.js 파일에 다음과 같은 설정값을 추가해주면 된다.

module.exports = {
  // rewrite
  async rewrites() {
    return [
      {
        // source : 유저가 진입할 path
        // destination : 유저가 이동할 path
        source: '/about',
        destination: '/',
      },
    ]
  },
  // redirect
  async redirects() {
    return [
      {
        source: '/about',
        destination: '/',
        permanent: true,
      },
    ]
  },
}

permanent 속성에 대해선 아래 속성에서 함께 소개하도록 하겠다.

source와 destination

path 매칭

:path

: 를 이용해 다이나믹한 path 값을 받아올 수 있다.

source: '/old-blog/:slug',
destination: '/news/:slug',

이렇게 설정되어있는 경우, /old-blog/apple 입력시 /news/apple로 /old-blog/banana 입력시 /news/banana로 이동된다.

만약 /old-blog/apple/green으로 입력시, 일치하는 경로가 없어 입력한 url(🍏) 그대로 이동된다.

:path*

하지만 다이나믹 path 옆에 *을 붙인다면?

source: '/old-blog/:slug*',
destination: '/news/:slug*',

/old-blog/apple/green -> /news/apple/green /old-blog/apple/green/delicious -> /news/apple/green/delicious 경로 길이에 상관 없이 rewrite 혹은 redirect 된다.

와일드 카드 / 정규식

도 사용 가능하다^ㅁ^

rewrite에서만 적용되는 자동 쿼리

rewrite에서는 생략된 path에 대해 자동 쿼리로 넘겨주는 속성이 있다. 예를 들어 다음과 같이 설정했을 때,

source: '/old-blog/:slug',
destination: '/news',

source에서는 다이나믹 Path를 받았지만, destination 그 어디에도 받아온 slug를 사용하는 곳이 없다. 이런 경우 slug로 입력받은 값은 destination의 쿼리로 넘겨진다.

module.exports = {
  reactStrictMode: true,
  async rewrites() {
    return [
      {
        source: "/test/:slug",
        destination: "/episodes",
      },
    ];
  },

// Episodes.tsx
const Episodes: NextPage = () => {
  const router = useRouter();
  console.log(router.query);
  ...
}

만약 *를 이용해 여러 path를 받는 경우엔..? /test/a/b/c/e/d 를 입력한 경우 배열로 해당 값을 받게 된다.

다른 속성들

기본적인 source와 destination 속성 외에도 다양한 속성들이 있다.

has & missing

rewrite나 redirect를 path뿐만 아니라 헤더나 쿠키, 쿼리 값이 일치하거나(has) 일치하지 않는 경우(missing)에만 실행할 수 있도록 사용하는 속성

has에 있는 속성은 전부 일치해야하며 missing에 있는 속성은 전부 일치해선 안된다.

속성 타입

{
    type : 'header' | 'cookie' | 'host' | 'query',
    key : String,
    value : String | undefined
}

사용 예시

module.exports = {
  // rewrite
  async rewrites() {
    return [
      {
        source: '/:path((?!another-page$).*)',
          has: [
            {
              type: 'header',
              key: 'x-redirect-me',
            },
          ],
            permanent: false,
              destination: '/another-page',
      },
      {
        source: '/:path((?!another-page$).*)',
        missing: [
          {
            type: 'header',
            key: 'x-do-not-redirect',
          },
        ],
        permanent: false,
        destination: '/another-page',
      },
      ]
  }
}

basepath

만약 module.exports에 basepath 설정을 해둔 경우, source path에 적용 여부를 나타낸다. false는 destination에 외부 링크가 사용된 경우에만 사용할 수 있는 속성이다.

module.exports = {
  basePath: '/docs',

  async redirects() {
    return [
      {
        source: '/with-basePath', // automatically becomes /docs/with-basePath
        destination: '/another', // automatically becomes /docs/another
        permanent: false,
      },
      {
        // does not add /docs since basePath: false is set
        source: '/without-basePath',
        destination: 'https://example.com',
        basePath: false,
        permanent: false,
      },
    ]
  },
}

permanent

✅ redirect에만 존재하는 속성값

permanent 속성값은 유저나 검색 엔진에서 해당 리다이렉트 값을 영구적으로 저장할 것인지에 대한 여부다. 만약 이벤트 페이지 이거나 임시 페이지인 경우는 false로 지정해주면 된다.

개인 공부 😭

올해 가장 못한 것 탑 3에 드는 개인 공부.. 약간의 찍먹들을 했다고 말하기 민망해서 큼지막하게 했다고 말할 수 있는 공부만 골라보았다. 근데 사실 이것도 맘에 안듦.. 내년에는 개인 공부하는 시간을 확보하고 계획을 세워서 진짜 알차게 보내고 싶다.

UI/UX 공부

작년 내 회고글에도 적혀있던 UI/UX 공부. 도널드 노먼씨의 책을 올해 초에 구매했으나 약 11개월 뒤인 12월에 부랴부랴 올해 버킷리스트를 채우기 위해 읽었다. 감성디자인과 디자인과 인간심리를 읽었는데, 아무래도 실무적인 UI/UX보단 이론에 가까워 실무적인 공부를 하고 싶다는 생각이 들었다. 프로젝트하는데 이왕이면 디자인도 하면 좋으니깐..!

🍀 2023 목표 : 피그마 공부하기

HTTP 완벽가이드

올해 생일선물로 받았던 HTTP 완벽가이드. 이것도 올해 안에 읽기를 목표로 하고 있었으나 어느덧 12월이 되어버렸고, 12월 목표로 HTTP 1회독하기 로 결정했다. 원래 목표는 읽으면서 벨로그에 정리하는 것이었는데, 읽다보니 배워야할 것들이 방대해 매일 하나씩 정리하기에는 버겁다고 느꼈고, 읽다가 지치는 것보다 완주가 목표였기 때문에 일단 1회독하고 추후 다시 천천히 읽으며 정리해보기로 했다. 그리고 그게 올해 목표...^ㅁ^..

얼레벌레 읽은 1회독이긴 했지만 내용이 굉장히 알차고 재밌었다. 그동안 추상적으로 알던 개념들을 퍼즐 맞추듯이 읽고 있어서 맞는 자리를 찾을 때마다 유레카를 외치게 된다. 물론 이게 10,000,000,000피스짜리 퍼즐인게 함정이지만..차근차근 정리하면서 공부하다보면 어떻게든 자리를 찾아가지 않을까..?

🍀 2023 목표 : HTTP 완벽 가이드 딥하게 공부하기

자바스크립트

올해 코어자바스크립트와 딥다이브 스터디를 진행했었다. 코어 자바스크립트를 먼저 공부하고 딥다이브를 진행했는데, 중요한 개념들을 미리 훑고 딥하게 공부해서 다행이다 싶었다. 물론 모든 내용을 기억하긴 어렵지만 자바스크립트를 사용하면서 의문을 가졌던 것들이나 새로운 기능들을 공부할 수 있어서 공부하는 동안 흥미진진했다. 딥다이브를 한번 더 읽어보고 싶지만 시간이 오래 걸릴 듯 하고 코어 자바스트립트는 몇번씩 반복해서 읽어봐야겠다.

타입스크립트

타입스크립트는 올해 처음 사용 및 공부하기 시작했다. 진짜 얕은 타입스크립트 실력으로 실무에도 투입되었고, 실무에서 타입스크립트를 사용하면서 레거시 코드를 만들어내는 나 자신을 용서하기 힘들었다. 그래서 올해 퇴사 후에 꼭 타입스크립트 공부를 제대로 하고 싶었고, 퇴사하자마자 타입스크립트 강의를 결제했다. 왜 업무하면서 공부하지 못했는지 궁금하겠지만 이건 차차 아래에서 다루도록 하고... 강의를 결제한 이유는 기강잡기와 감잡기 두가지 이유에서였다. 기강잡기는 내 심리적인 문제가 컸고, 감잡기는 길을 잘못든 타입스크립트 사용을 바로 잡아줄 멘토가 필요해서였다. 아무튼 좋은 선택이었고, 아는만큼 보인다고 이제는 고칠 수 없는 지난 회사 코드들을 당장이라고 회사로 찾아가 고치고 싶은 마음이 굴뚝같아져 더욱 괴로워졌지만, 앞으로 사용하는 타입스크립트는 더이상의 이런 불상사가 없도록 더 공부하고 더 많이 사용하고 싶다.

🍀 2023 목표 : 이펙티브 타입스크립트 다시 도전하기

진행한 프로젝트

되게 올해가 빨리간 기분이었는데, 프로젝트 정리를 하면서 이게 올해였다고..??! 화들짝 놀랐다. 시간 가는게 아무 것도 없이 빠르게 지나간 줄 알았는데 나름 알차게 보냈구나 싶어서 혼자 괜시리 뿌듯했다,, 작년에 프론트엔드를 공부하기로 결정하고 가장 하고싶었던게 프로젝트였는데 아쉬웠던 점을 이뤄 보람찼다. 올해에는 좀 더 양질의 프로젝트를 할 수 있기를..!

감귤마켓

✔️ 프로젝트 진행 과정 확인하기 감귤마켓 1 감귤마켓 2

HTML, CSS, JS로 진행한 프로젝트로 멋사 수업에 포함되어있던 팀프로젝트였다. 프로젝트 경험이 별로 없었지만 그간의 경험들을 토대로 PM 역할을 하기 위해 노력했다. 초보 얼레벌레 리더였지만 잘 따라와준 동료들 덕분에 필수 구현 사항들을 전부 구현할 수 있었고, 마지막 동료 피드백으로 칭찬을 받아서 매우 뿌듯했다. (피드백 결과를 5월에서야 받긴 했지만 예상치 못한 선물이라 기분이 좋았다 😉)

스페이스로그

스페이스로그 진행과정 확인하기 스페이스로그 글 목록

멋사 수업에서 가장 좋았던 점은 개발자 친구들을 사귈 수 있다는 점이었다. 비전공자의 숙원같은 느낌이랄까.. 친구를 사귀어야지 하고 복학했는데 코로나가 터져버린 복학생의 비애랄까.. 암튼 그런 한(?)이 있었는데, 이곳에서 스데브를 만났다. 규리님을 주축으로 진짜 제대로 프로젝트 한번 해 보자! 하고 모였고 벨로그를 따라하되, 우리만의 무언가를 넣어보자! 하고 시작한 프로젝트였다. (여담이지만 '우리만의 무언가'로 다크모드를 추가했는데, 개발 도중 벨로퍼트님이 만들어버리셨다. 😨)

개발하면서 생각보다 벨로그에 기능이 많다는걸 느꼈으며, 이 많은 기능들을 구현하면서 그만큼 많이 성장했다. 특히 이 때 next.js로 개발을 진행했는데, 이 때 구현하고 공부한 많은 기능들이 실무에서 굉장히 큰 도움이 되었다.

테오의 구글 스프린트 : 뽀프만

스프린트 후기 npm에 react 컴포넌트 배포 🙌 ( + 테오의 구글 스프린트 4기 후기 )

프로젝트에 목이 마른 복학생이었던 졸업생이 발견한 테오 스프린트. 내가 테오의 글을 볼 땐 2기가 끝난지라 댓글에 추후 열리게 되면 알려달라고 작성해두었고, 테오가 메일을 보내주었다.

짧지만 알차게 프로젝트를 만들어갈 수 있다는 생각에 바로는 아니고 조금 고민하다가 신청했다. 3기 신청 메일이었으나 조금 늦게 결심해 4기로 들어갔다. 하지만 너무 좋은 선택이었고, 좋은 사람들을 만나 즐거운 프로젝트를 할 수 있었다. 프로젝트가 끝난 이후에도 준의 추진력으로 함께 스터디를 진행했고 많이 배울 수 있는 사람들을 만나 올해 더 성장할 수 있었다. 동기 유발 인간들.. 💪

다음에는 꼭 직접 npm 배포해보기!

Loglog

loglog 진행과정 확인하기 log log 프로젝트 ) 프로젝트 설명

1년 전 규리님과 함께 기획+개발 모두 포함 이틀동안 진행했던 goodbye2021이라는 회고 프로젝트가 있었다. 1년 회고용으로 만들어두었지만 월별 회고용도로 1년동안 잘 쓰다가 연말이 다가오고 사용자 입장에서 수정이 필요하다고 생각했던 부분들을 디벨롭해 프로젝트를 업데이트 했다. 기획단계에서 더 많은 기능 추가를 하고 싶었으나 올해 말에 다시 돌아오기로 했다. 일단 1년 회고를 가장한 한달 회고용 웹으로 잘 써먹어야지.

Amoo

연말에 준이 플젝 하나 하자고 제안해서 나오게된 아무 게임! 이것도 회고글이랑 고민했던 부분 글을 적어야하는데 테스트 케이스 적용하고 해야지 했다가 아직까지 못쓰고 있다. 허허. 타입스크립트를 막 제대로 공부하고 진행했던 프로젝트라서 규모가 크진 않지만 공부한 여러가지를 적용해볼 수 있어서 재밌었다. 연말까지 알차게 보냄..!

🍀 2023 목표 : 회고글 작성하기 / 테스트 코드 적용하기

취업

올해 초 회사에서 쓰일 프로덕트의 프로젝트 제안을 받고 프로덕트를 만들다가 4월 입사 제안을 받아 입사했다. 제안을 준 프론트엔드 CTO와 나와 함께 입사한 (역시) 프론트엔드 신입 개발자분 이렇게 셋으로 개발팀이 꾸려졌고, 5월에 기획이 엎어져 8월 오픈을 목표로 처음부터 프로덕트를 다시 만들게 되었다.

웹 및 앱 오픈이 회사의 사활이 걸린 문제였기 때문에 밤낮 평일 주말할 것 없이 최선을 다해 개발에 임했고, 계속해서 바뀌는 기획에 맞춰 열심히 커뮤니케이션하며 8월 오픈을 향해 달렸다. 프론트로만 이뤄진 개발팀이다보니 자연스럽게 백엔드도 다루게 되었고, API 개발과 프론트 개발, 팀 내에서 사용할 어드민 페이지까지 모두 다뤄야만 했다.

(눈물없이 볼 수 없는 커밋...)

약속했던 8월이 오고 슬프게도 오픈이 성공적이지는 못했고 갑작스런 CTO의 퇴사로 다른 시니어분이 오기까지 한달여간 신입 두명이서 신규 기능 오픈 + 에러 해결을 해야하는 상황이 되었다. 8월이 내 지난 인생에서 가장 힘들었던 달이었다. 그치만 힘든 시간이었지만 인생 업적에 남길 수 있는 일이라고 좋게 생각하려고 한다. 🥲 한달간 웹에서 터지던 에러를 잡고, 안정화에 포커스를 두고 개발했다. 시니어분이 오시고 인수인계라고 할 것도 없지만,, 약 한달 정도의 업무 정리를 끝으로 퇴사했다.

🌞 GOOD

• 결국에 남는 건 사람이라고 했던가. 사람에게 받은 상처 사람으로 회복한다고, 힘든 시간들을 함께 보내고 나니 회사 사람들과 더욱 끈끈해졌다. 아쉽게도 회사를 떠나게 되었지만, 함께 울고 웃던 나날들 덕분에 그 힘든 시간들을 견딜 수 있었다.
• 프론트엔드 일에만 한정되지 않고 백엔드 영역과 PM, 기획 영역까지 넘나들어본 것. 역할이 분배되어 있지 않던 상황이었고, 누군가는 해야하는 상황이었기 때문에 내가 했다. 덕분에 한 분야에만 한정되지 않고 더 다양한 업무를 할 수 있었다.

🌧 BAD

• 업무를 하면서 내가 부족하다고 굉장히 많이 느끼게 되었다. 일을 하고 있던 중에는 당장의 문제를 해결해야했기 때문에 나 자신에 대한 질문까진 닿지 않았지만, 일을 관두고 난 뒤에 굉장히 고민이 많아졌다. 크게 타입스크립트에서부터 시작해서, 디자인 패턴이라던가 테스트코드라던가, 구조를 잡고 프로젝트에 들어갔다면 놓치는 부분을 줄일 수 있지 않았을까? 최적화 할 수 있는 방법이 더 없었을까? 등등 질문들이 꼬리에 꼬리를 물어 아직 배울 공부가 많다고 느껴졌다.
• 일하면서 해결한 코드들을 정리해두지 않은 것. 완벽한 글이 아니더라도 정리해둘 걸 그랬다. 회사 코드라서 어디서부터 어디까지 오픈할 수 있을까 고민이 많았고 이에 답해줄 사수도 없어서 어영부영 넘어가버렸다..

🌈 FOR BETTER

• 업무를 시작하게 되면 꼭 업무 일지 쓰기
• 회사 사람들과 일 진행 사항에 대한 오버 커뮤니케이션 하기
• 공부하고 싶은 것들 주저하지 말고 그때 그때 공부하기
• 프론트에 한정된 공부하지 않기. 모든 상황에 대응하기 위해선 두루두루 할 수 있어야한다. (근데 일단 프론트 공부부터 제대로 하고..)

총평

정말이지 다사다난한 해였다. 그만큼 많이 성장한 해이기도 하고, 그만큼 성장해야겠다고 결심한 해이기도 하다. 회사를 관두고 혼자 생각할 시간이 많아지면서 개발을 관둬야하나라는 생각까지 갔으나 10년은 더 해보기로 마음먹었다. 10년은 해봐야 해봤다고 말할 수 있지 않을까.

올해는 목표 설정을 만다라트로 했는데 이 중 개발과 커리어 테마의 목표를 공유해둘까 한다. 목표는 모름지기 많이 공유할 수록 성공 확률이 높아지는 법이니깐.

전부 다 달성보다는 여러가지 목표를 정해놓고 최대한 많이 달성하는데 의미를 두려고 한다. 2023년도 한번 더 가보자고~

Ensure your Next.js app's performance is top-notch with Lighthouse CI and GitHub Actions을 읽고 따라해보며 겪은 이슈

Error: No URLs provided to collect
    at startServerAndDetermineUrls (/Users/minjukim/futurama.vercel.com/node_modules/@lhci/cli/src/collect/collect.js:149:36)

해당 글을 무작정 따라하다가 다음과 같은 에러가 생겼다🥲 그래서 제대로 공식문서 : Google Chrome Lighthouse ci 읽으면서 따라해본 방법 정리

설치 방법

1. @lhci/cli 설치

npm i --save-dev @lhci/cli
yarn add @lhci/cli --dev

2. lighthouserc.js 파일 생성

module.exports = {
  ci: {
    collect: {
      startServerCommand: "npm run start",
      startServerReadyPattern: "ready on",
      url: ["http://localhost:3000"],
    },
    upload: {
      target: "temporary-public-storage",
    },
  },
};

기본적으로 lighthouse 검사를 3번 실행하게 된다. 만약 횟수를 정하고 싶다면 "numberOfRuns": 1(횟수) 설정을 추가해주면 된다.

"collect": {
    "startServerCommand": "npm run start",
    "startServerReadyPattern": "ready on",
    "url": [
        "http://localhost:3000"
        ],
    "numberOfRuns": 1,
}

3. Secret key 발급 받기

Lighthouse ci market에 접속해 LHCI_GITHUB_APP_TOKEN를 발급받는다.

발급 받은 키를 잘 복사해 해당 프로젝트 레포지토리의 Settings > Secrets > Actions 에 들어가 new repository secret 버튼을 클릭한뒤

복사한 키를 입력해 저장한다.

4. 프로젝트에 ci 파일 생성

.github/workflows 에 ci.yml 파일을 생성한다.

.github 폴더는 프로젝트 파일의 최상위에 생성하면 된다.

ci.yml에 다음과 같이 작성해준다

name: CI
on: [push]
jobs:
  lighthouseci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 16
      - run: npm install && npm install -g @lhci/cli@0.8.x
      - run: npm run build
      - run: lhci autorun
        env:
          LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

5. gitignore 수정

로컬에서 lhci 명령어를 돌리게 되면 .lighthouseci라는 폴더가 생성되면서 로그가 찍히게 된다. 이 파일이 깃헙에 올라가는 걸 막기 위해 .gitignore 파일에 .lighthouseci/를 추가해준다.

6. 끝!

요렇게 돌아가면서

실패시 다음과 같이 뜨고

성공시에는 다음과 같이 뜬다.

성공 여부와 관계없이 lhci/url 이 생긴걸 확인할 수 있는데, details를 클릭하면

이렇게 lighthouse 결과지 페이지를 생성해준다.

lighthouserc.js 파일 설명

왜 언급된 글에서는 .lighthouserc.json 파일을 생성하라고 했는데, lighthouserc.js가 제대로 동작했을까?

Lighthouse CI가 configuration 파일을 다음과 같은 우선순위로 찾는다고 한다.

1. .lighthouserc.js
2. lighthouserc.js
3. .lighthouserc.json
4. lighthouserc.json
5. .lighthouserc.yml
6. lighthouserc.yml
7. .lighthouserc.yaml
8. lighthouserc.yaml

최상위에 파일이 존재하는게 아니라 다른 곳에 파일을 두고 싶다면 lhci 명령어 옆에 항상 --config=./대충/파일/위치 를 붙여 파일 위치를 알려주기!

여기서 주의할 점은 어떤 파일이던 상관없지만 파일 확장자에 따라 형식을 맞춰 작성해주어야 한다.

js

module.exports = {
  ci: {
    collect: {
      // collect options here
    },
    assert: {
      // assert options here
    },
    upload: {
      // upload options here
    },
    server: {
      // server options here
    },
    wizard: {
      // wizard options here
    },
  },
};

json

{
  "ci": {
    "collect": {
      // collect options here
    },
    "assert": {
      // assert options here
    },
    "upload": {
      // upload options here
    },
    "server": {
      // server options here
    },
    "wizard": {
      // wizard options here
    }
  }
}

yml

ci:
  collect:
    # collect options here

  assert:
    # assert options here

  upload:
    # upload options here

  server:
    # server options here

  wizard:
    # wizard options here

lighthouserc의 다양한 설정들

위에 파일을 보면 알겠지만 lighthouserc에는 다양한 설정들이 있다. 기본적으로 collect와 upload만 사용하긴 했지만, 공식문서에서는 assert 사용도 권장하고 있다. (assert 이외의 설정 설명이나 디테일한 설명은 여기 참고하기!)

assert는 lighthouse 실행 결과에서 낮은 점수가 나오는 경우 CI 단계에서 에러가 나도록 해주는 설정이다. assert 설정 안에서도 preset, assertion 등 세부설정이 있다.

preset은 "lighthouse:all", "lighthouse:recommended", "lighthouse:no-pwa" 중 선택할 수 있다.

assertion 은 검사 항목들의 기준을 수정할 수 있다. 검사항목 : level | [level, options]의 형식으로 작성된다. 검사항목들은 여기에서 확인 할 수 있다. level 설정은 세가지로 나뉜다.

option의 기본값은 {"aggregationMethod": "optimistic", "minScore": 1} 이다. aggregationMethod는 검사 점수 측정 방법으로 세가지 항목으로 이뤄져 있다.

{
  "ci": {
    "assert": {
      "assertions": {
        "first-contentful-paint": "off",
        "installable-manifest": ["warn", {"minScore": 1}],
        "uses-responsive-images": ["error", {"maxLength": 0}]
      }
    }
  }
}

🍀 TMI

모든 Clickable한 요소의 크기는 48*48 이상이어야 한다.

⬆️ 모바일에서도 사용해보세요!

프로젝트 설명

loglog는 1년을 가볍게 회고할 수 있는 웹 서비스입니다. 여섯개의 키워드를 선택해 키워드에 해당하는 사진을 선택하거나 키워드에 대한 글을 작성할 수 있습니다. 당신의 한 해는 어떤 해였나요? 결과페이지에서 포인트 색상을 정해 색상을 입히고 이미지를 저장해 친구와 공유해보세요!

작년에 규리님과 이틀에 걸쳐 급하게 만들었던 연말 회고 페이지를 리뉴얼하기로 했다. 그동안 업데이트를 하고 싶었으나, 너무 바쁜 일상으로 인해,, 손 댈 엄두를 내지 못했는데 연말이 다가오고 규리님이 이제 슬슬 업데이트를 해볼까요 하고 제안을 주셔서 드디어 한을 풀 수 있게 되었다.

우선 프로젝트 이름을 변경했다. 기존 프로젝트 이름은 goodbye-2021로 21년 회고에 포커싱되어있기 때문에, 년도에 상관없이 사용할 수 있도록 이름을 loglog로 변경했다.

스펙은 이전과 동일하게 가져가되, 예전 기능에서 우리가 사용하면서 필요하다고 생각했던 여러 기능을 추가하기로 했다. 서버가 필요하지 않은 기능들이다보니 프론트 스택만을 사용했다.

member

김민주

이규리

Product

피그마 이미지 github loglog 서비스 페이지

stack

Frontend

• React
• styled-component
• Recoil

library

• react-grid-layout (최종 적용 ❌)
• html2canvas
• tinycolor2

페이지

메인 페이지

키워드 선택 페이지

결과 페이지

상세 기능

이번 업데이트는 다음과 같은 기능들이 추가되었다.

1. 전체적인 UI 수정

1-1. 키워드 페이지 통합

기존 페이지는 키워드 선택 페이지와 회고 입력 페이지가 분리되어, 만약 작성 중 키워드를 수정하고 싶다면 이전 페이지로 돌아가야했다. 유저 입장에서 사용하면서 키워드를 중간에 수정할 수 없음에 불편함을 느꼈고, 페이지를 통합하기로 했다.

alt="" /><br/><sub><b>키워드 선택 페이지 (전)</b></sub> </td> <td align="center"> <img src="https://velog.velcdn.com/images/deli-ght/post/5956eaf0-ee3b-441b-b751-a9b7a419210c/image.png" alt="" /><br/><sub><b>회고 입력 페이지 (전)</b></sub> </td> <td align="center"> <img src="https://i.imgur.com/3jZ22Cp.png" alt="" /><br/><sub><b>통합된 키워드 선택 페이지 (후)</b></sub> </td>

1-2. 메인 컬러셋 변경

컬러를 수정할 수 없던 기존 버전과 달리 이번 버전에서부터는 컬러를 수정할 수 있기 때문에 전체 컬러를 블랙앤 화이트로 맞춰 유저가 선택한 어떤 컬러에도 어울릴 수 있도록 했다.

1-3. 결과 레이아웃 수정

글의 길이에 따라 컨텍스트의 높이가 달라지는 레이아웃을 mansonry라고 한다. (나도 이번에 처음 알게 되었다.) 대표적인 예시로 핀터레스트 UI가 있다.

이 레이아웃을 만들기 위해 처음에는 라이브러리를 사용해볼까 했으나 이미지의 경우 높이를 일정하게 해주는 예외사항이 있어 커스텀이 가능하도록 코드로 구현하는 방법을 찾아보았다.

export const MasonryGrid = ({ datas, pointColor }) => {
  useEffect(() => {
    masonryLayout();
  }, []);

  return (
    <GridContainer className="masonry-container">
      {datas?.map((data, index) => {
        const { content, keyword } = data;

        if (content)
          return (
            <AnswerBlock
              key={keyword}
              data={data}
              data-type="text"
              bgColor={getRandomColor(index, pointColor)}
            />
          );
        return <AnswerImage key={keyword} data={data} data-type="image" />;
      })}
    </GridContainer>
  );
};

const GridContainer = styled.div`
  display: grid;
  box-sizing: border-box;
  width: 100%;
  grid-template-columns: repeat(2, 1fr);
  gap: 5px;
  grid-auto-rows: 5px;
`;

먼저 컨텍스트를 담을 컨테이너를 그리드로 만들어준다. 이때 그리드를 모눈종이처럼 촘촘이 나눠줘야하기 때문에 나는 5px로 높이를 설정해주었다. gap의 경우 역시 너무 간격이 크면 줄 길이에 따라 하단이 너무 길어지는 UI가 나오기 때문에 열 높이와 똑같이 5px로 설정해주었다.

이렇게 만들어진 grid에 각각의 컨텍스트가 길이에 따른 높이값을 가지도록 계산해준다.

export const masonryLayout = () => {
  const container = document.querySelector(".masonry-container");
  const masonryContainerStyle = getComputedStyle(container);

  const autoRows = parseInt(
    masonryContainerStyle.getPropertyValue("grid-auto-rows"),
  );

  document.querySelectorAll(".masonry-item").forEach((elt) => {
    const scrollHeight = elt.scrollHeight;

    elt.style.gridRowEnd = `span ${Math.ceil(scrollHeight / autoRows / 1.7)}`;
  });

  document.querySelectorAll(".masonry-item-image").forEach((elt) => {
    const imgWidth = container.scrollWidth / 2 - 10;

    elt.style.gridRowEnd = `span ${Math.ceil(imgWidth / autoRows / 2)}`;
  });
};

각각이 가지게 될 높이를 열 높이로 나눠준다. 그렇게 나눠진 값만큼 grid의 높이를 차지하는 방식으로 계산하는데, 이 때 나는 하단이 너무 길어지는 현상이 생겨 1.7로 한번 더 나누어 주었다. 1.7이라는 깔끔하지 않은 숫자로 나눈 이유는.. 1과 2 사이에서 열심히 테스트해보다가 1.7이 가장 깔끔한 UI가 나와 1.7로 지정했다.

이미지의 경우, 처음에는 1:1 비율로 지정해주고 싶어 처음에는 별다른 계산 없이 aspect-ratio를 이용해 1:1 비율로 지정한 뒤, 넓이만큼 높이값을 가지도록 했으나 이런 경우 aspect-ratio의 특성에 의해 높이에 따라 넓이가 계산되고 넓이에 따라 높이가 계산되고가 반복되어 UI가 깨지는 문제가 발생했다. 어쩔 수 없이 aspect-ratio 설정을 빼고 글자와 똑같이 넓이값을 받아와 행 높이에 맞춰 나눠주도록 했다.

2. 컬러 선택 기능

배포 후 가장 많은 요청을 받았던 컬러 선택 기능을 드디어 추가했다. 모든 칸의 컬러를 선택하는 방법도 있겠지만, 모든 컬러를 선택하도록 하는 것이 유저에게 피로감을 줄 수 있겠다는 생각을 해 포인트 컬러를 기반으로 명도가 변경되도록 수 정했다.

2-1. 포인트컬러 직접 선택

포인트 컬러 직접 선택 input의 경우, 기본 input을 이용했다. input의 타입을 color로 지정해주면, 유저가 컬러 피커를 이용할 수 있다.

크롬 컬러 피커

사파리 (웹) 컬러 피커

사파리 (모바일) 컬러 피커

기본 input 모양을 커스터마이징 하고 싶어 input의 display : none 처리 하고 label을 클릭하면 컬러 피커가 뜨도록 코드를 작성해주었다. 이렇게 코드를 작성했더니 크롬에서는 원하는대로 동작하지만 사파리에서는 동작하지않는 문제가 발생했다...!!😨

이 문제를 해결하기 위해 display 속성이 아닌 visibility : hidden 을 사용해보았으나 역시나 뜨지 않았고, opacity : 0 을 설정해주었더니 그제서야 비로소 동작했다.

const ColorInput = styled.input`
  opacity: 0;
`;

2-2. 포인트컬러 랜덤 선택

컬러를 랜덤으로 설정하는 코드는 tinycolor2 라이브러리를 이용하였다! 해당 코드에 대한 설명은 글로 따로 적어두었으니 tinycolor2 라이브러리 사용 후기에서 확인하기!

해당 기능은 가장 반응이 좋았다! 😎

3. 이미지 회고 타입 추가

텍스트만 입력 가능하던 기존 버전과 달리 이번 버전에서는 이미지도 입력할 수 있도록 기능이 추가되었다!

데이터를 서버에 저장하거나 공유할 필요가 없어 이미지 서버를 따로 구축하진 않았고 blob 형태로 프로젝트 내에서 계속 사용하도록 했다.

const onFileChanged = (ev) => {
    const {
      target: { files },
    } = ev;
    if (files) {
      const { length: FileLength } = files;
      for (let i = 0; i < FileLength; i++) {
        const reader = new FileReader();
        reader.addEventListener("loadend", (event) => {
          if (!event.target) return;
          const { result } = event.target;
          if (result) {
            handleSaveImg(result);
          }
        });
        reader.readAsDataURL(files[i]);
      }
    }
    ev.target.value = "";
  };

4. 이미지 저장 기능

이미지 저장 기능은 라이브러리를 사용해 쉬울 것이라고 생각했으나, 예상외의 복병이 2가지 존재했다 🥲

4-1. html2canvas에서 지원하지 않는 css 속성

유저가 추가한 이미지를 비율에 맞춰 보여주기 위해 처음에는 background에 이미지를 넣어주었다. 하지만 background로 이미지를 넣는 경우 이미지가 심하게 깨지는 문제가 있어 이를 해결하기 위해 image 태그에 넣는 것으로 변경했다.

image 태그에 넣어 이미지의 위치를 조절하기 위해 image 자체에 object-fit를 넣어주었다. 웹 상에서는 원하는 대로 잘 나타났지만.. 이미지를 다운로드 받았더니 이미지가 확대되는 문제가 발생했다. (아놔)

사이트에서 살펴보니 object-fit을 지원하고 있지 않고 있었다.

문제를 해결하기 위해 이미지 크기를 수동으로 조절하는 코드를 추가했다. 만약 이미지의 넓이가 높이보다 크다면 높이를 높이에 맞춰 이미지를 채우고, 높이가 넓이값보다 크다면 넓이에 맞춰 이미지를 채우는 방식을 사용했다.

 useEffect(() => {
    const myImgs = document.querySelectorAll(".my-images");

    myImgs.forEach((myImg) => {
      const imgWidth = myImg.clientWidth;
      const imgHeight = myImg.clientHeight;

      if (imgWidth > imgHeight) {
        myImg.style.height = "100%";
      } else {
        myImg.style.width = "100%";
      }
    });
  }, []);

4-2. 인앱 브라우저에서 이미지 다운로드 불가

어느정도 기능 구현이 완료된 이후, 주변에 베타 테스트를 부탁했다. 카카오톡을 이용해 링크를 전달했는데 문제가 발생했다. 인앱 브라우저에서는 이미지 다운로드가 불가능했던 것..! 앱이 자체 앱이 아니라 사파리나 크롬과 같은 브라우저로 이동시키는 코드를 추가 할 수 없었고, 웹 자체에 이를 대처하는 코드를 추가해야했다.

방법을 찾던 도중 다음의 블로그를 발견했다. 카카오, 네이버 인앱에서 외부 브라우저 띄우는 방법 정리

기존에는 링크 프로토콜 변경을 통해 ios에서 사파리가 열리도록 하는 편법을 썼으나 업데이트 이후로는 이 방법이 막혔다고 한다,, 현재로서는 유저가 직접 링크를 복사해서 이동하는 방법밖에 없어서 블로그에 나와있던 코드를 다음과 같이 수정했다.

const copyUrl = () => {
    window.navigator.clipboard.writeText("https://loglog.co.kr").then(() => {
      alert("링크가 복사되었습니다! 즐거운 한해 마무리 하세요~");
    });
  };
  if (
    navigator.userAgent.match(
      /inapp|NAVER|KAKAOTALK|Snapchat|Line|WirtschaftsWoche|Thunderbird|Instagram|everytimeApp|WhatsApp|Electron|wadiz|AliApp|zumapp|iPhone(.*)Whale|Android(.*)Whale|kakaostory|band|twitter|DaumApps|DaumDevice\/mobile|FB_IAB|FB4A|FBAN|FBIOS|FBSS|SamsungBrowser\/[^1]/i,
    )
  ) {
    if (navigator.userAgent.match(/iPhone|iPad/i)) {
      return (
        <Container>
          <Caution>
            더 나은 환경을 위해 외부 브라우저로 이동해 이용해주세요! 🥲
          </Caution>
          <CopyButton type="button" onClick={copyUrl}>
            링크 복사하기
          </CopyButton>
        </Container>
      );
    } else {
      window.location.href =
        "intent://" +
        window.location.href.replace(/https?:\/\//i, "") +
        "#Intent;scheme=http;package=com.android.chrome;end";
    }
  } else {
    return (
      <Container>
        <Header>
          안녕<span>2022</span>
        </Header>
        <Description>
          <Strong>키워드</Strong>와 <Strong>색</Strong>으로
          <br />
          나의 2022 기록하기
        </Description>
        <Wrapper>
          <BookImage src="/image/favorite-book.png" alt="" />
          <FormName />
          <Button toLink={"/answer"} children={"2022 정리하기"} />
        </Wrapper>
      </Container>
    );
  }

마무리

12월 15일을 데드라인으로 정했으나 생각치 못한 이슈들도 있고, 수정하고 싶은 부분들도 생겨 딜레이되었다..! 계속해서 수정사항들을 업데이트 할 예정이니 많관부!

여러 타입의 컬러를 다양하게 변형 및 활용할 수 있는 라이브러리

공식 문서

테스트 홈페이지 깃헙 코드

사용방법

설치

npm install tinycolor2
yarn add tinycolor2

사용

다양한 타입의 컬러 형식 사용 가능

// Hex, 8-digit (RGBA) Hex
tinycolor("#000");
tinycolor("000");

// RGB, RGBA
tinycolor("rgb (255, 0, 0)");
tinycolor("rgb 255 0 0");

// HSL, HSLA
tinycolor("hsl(0, 100%, 50%)");
tinycolor("hsla(0, 100%, 50%, .5)");

// HSV, HSVA
tinycolor("hsv(0, 100%, 100%)");
tinycolor("hsva(0, 100%, 100%, .5)");

// Named
tinycolor("RED");
tinycolor("blanchedalmond");

지원하는 기능

지원하는 여러가지 기능 중 내가 유익하다고 생각한 것들을 몇가지만 뽑아보았다.

1. isLight() / isDark()

해당 컬러가 밝은 색인지, 어두운 색인지 boolean 값으로 알려주는 함수 이번 프로젝트에서는 현재 백그라운드 컬러에 따라 폰트 컬러가 바뀌는 기능에 사용해보았다.

let color1 = tinycolor("#fff");
color1.isLight(); // true

let color2 = tinycolor("#000");
color2.isLight(); // false

// styledComponent
color: ${({ bgcolor }) =>
    tinycolor(bgcolor).isDark() ? "#ffffff" : "#000000"};

2. lighten() / darken()

원하는 만큼 현재색에서 밝은 컬러 혹은 어두운 컬러를 뽑아내준다.

tinycolor("#f00").lighten().toString(); // "#ff3333"
tinycolor("#f00").lighten(100).toString(); // "#ffffff"

tinycolor("#f00").darken().toString(); // "#cc0000"
tinycolor("#f00").darken(100).toString();

지금 프로젝트에서는 랜덤값에 따라 칸이 포인트 컬러보다 밝거나 어둡게 설정되도록 코드를 작성하였다.

const bgColor = Math.floor(Math.random() * 1)
      ? tinycolor(pointColor).darken(randomValue * 10)
      : tinycolor(pointColor).brighten(randomValue * 10);

3. random()

랜덤으로 색상을 뽑아준다. 진짜 좋다고 생각한 기능..!

let randomColor = tinycolor.random().toHexString() // #ffe234;

궁금증

어떻게 글씨체 dark/light를 구분할까

tinycolor.prototype = {
    isDark: function() {
        return this.getBrightness() < 128;
    },
    isLight: function() {
        return !this.isDark();
    },
    getBrightness: function() {
        //http://www.w3.org/TR/AERT#color-contrast
        var rgb = this.toRgb();
        return (rgb.r * 299 + rgb.g * 587 + rgb.b * 114) / 1000;
    ...

코드를 살펴보면 getBrightness() 함수를 이용해 밝기 정도를 계산한 뒤, 절반인 128 이하면 dark, 이상이면 light로 구분하였다. 주석 처리된 링크로 들어가보면 계산식을 확인할 수 있는데, RGB 컬러를 YIQ 형식으로 변경할 때 사용되며 컬러 밝기 정도를 확인하는 공식이라고 한다. 계산값은 0~255 사이의 값이 나온다.

lighten/ darken 방식

function lighten (color, amount) {
    amount = (amount === 0) ? 0 : (amount || 10);
    var hsl = tinycolor(color).toHsl();
    hsl.l += amount / 100;
    hsl.l = mathMin(1, mathMax(0, hsl.l));
    return tinycolor(hsl);
}

코드를 살펴보니 HSL이라는 값을 이용했다. HSL이란 인간의 시각적 특징을 고려해 만들어진 색공간으로, H는 적색을 기준으로한 색상 각도인 Hue를 의미하고 S는 채도를 의미한다. L는 명도(Lightness)의 줄임말로 해당 코드에서는 명도의 값을 조절하며 컬러값의 밝기를 조절하는 것을 확인할 수 있다.

비슷한 방식으로 brighten 함수가 있는데, 이건 rgb를 이용하고 있다.

function brighten(color, amount) {
    amount = (amount === 0) ? 0 : (amount || 10);
    var rgb = tinycolor(color).toRgb();
    rgb.r = mathMax(0, mathMin(255, rgb.r - mathRound(255 * - (amount / 100))));
    rgb.g = mathMax(0, mathMin(255, rgb.g - mathRound(255 * - (amount / 100))));
    rgb.b = mathMax(0, mathMin(255, rgb.b - mathRound(255 * - (amount / 100))));
    return tinycolor(rgb);
}

코드를 보다보면 mathMin(a, mathMax(b, value)); 형식의 함수가 비슷하게 연달아 나온다. 이렇게 사용하는 이유는 a부터 b사이의 값만 나오도록 로직을 설계하기 위해서이며 Min안의 a 값은 항상 max 안의 b 값보다 커야한다.

웹의 특정 컴포넌트를 canvas 형태로 변경하고 싶을 때 사용하는 라이브러리

공식 문서

공식 홈페이지 깃헙 코드

사용 방법

설치

npm install --save html2canvas
yarn add html2canvas

사용

html2canvas(element).then(function(canvas) {
    document.body.appendChild(canvas);
});

html2canvas의 파라미터로 canvas형식으로 변환을 원하는 노드 객체를 넣어주면 된다.

  const captureResult = () => {
    html2canvas(document.getElementById("capture"), {
      backgroundColor: "#000000",
    }).then(function (canvas) {
      const downloadLink = document.createElement("a");
      downloadLink.download = "filename.png";
      downloadLink.href = canvas.toDataURL();
      downloadLink.click();
    });
  };

내가 작성한 코드의 경우, 버튼 클릭시 캔버스를 이미지 형식으로 다운 받을 수 있도록 작성한 코드로 promise의 결과값으로 canvas를 받아 png 형식으로 다운로드 받을 수 있도록 해주었다.

원리

처음 캔버스로 바꿀 노드를 받아오게 되면, 해당 노드를 캔버스 내에 그리기 위해 클론하는 과정을 거친다.

// html2canvas/src/index.ts
const renderElement = async (element: HTMLElement, opts: Partial<Options>): Promise<HTMLCanvasElement> => {
    if (!element || typeof element !== 'object') {
        return Promise.reject('Invalid element provided as first argument');
    }

  // ... 생략

    const cloneOptions: CloneConfigurations = {
        allowTaint: opts.allowTaint ?? false,
        onclone: opts.onclone,
        ignoreElements: opts.ignoreElements,
        inlineImages: foreignObjectRendering,
        copyStyles: foreignObjectRendering
    };

    const documentCloner = new DocumentCloner(context, element, cloneOptions);
    const clonedElement = documentCloner.clonedReferenceElement;
    if (!clonedElement) {
        return Promise.reject(`Unable to find element in cloned iframe`);
    }

노드를 클론하는 DocumentCloner는 재귀 형식으로 노드를 타고 내려가면서 clone을 생성한다.

https://github.com/niklasvh/html2canvas/blob/6020386bbeed60ad68e675fdcaa6220e292fd35a/src/dom/document-cloner.ts#L48

클론이 끝나고 나면, 원하던 컴포넌트의 높이와 넓이에 맞는 캔버스 객체를 하나 생성해준다.

// html2canvas/src/render/canvas/canvas-renderer.js
 constructor(context: Context, options: RenderConfigurations) {
        super(context, options);
        this.canvas = options.canvas ? options.canvas : document.createElement('canvas');
        this.ctx = this.canvas.getContext('2d') as CanvasRenderingContext2D;
        if (!options.canvas) {
            this.canvas.width = Math.floor(options.width * options.scale);
            this.canvas.height = Math.floor(options.height * options.scale);
            this.canvas.style.width = `${options.width}px`;
            this.canvas.style.height = `${options.height}px`;
        }
        this.fontMetrics = new FontMetrics(document);
        this.ctx.scale(this.options.scale, this.options.scale);
        this.ctx.translate(-options.x, -options.y);
        this.ctx.textBaseline = 'bottom';
        this._activeEffects = [];
        this.context.logger.debug(
            `Canvas renderer initialized (${options.width}x${options.height}) with scale ${options.scale}`
        );
    }

앞서 클론한 노드들을 바탕으로 해당 노드의 타입을 구분에 이에 맞춰 만들어진 캔버스안에 그려내는 방식으로 동작한다.

async renderNodeContent(paint: ElementPaint): Promise<void> {
        this.applyEffects(paint.getEffects(EffectTarget.CONTENT));
        const container = paint.container;
        const curves = paint.curves;
        const styles = container.styles;
        for (const child of container.textNodes) {
            await this.renderTextNode(child, styles);
        }

        if (container instanceof ImageElementContainer) {
            try {
                const image = await this.context.cache.match(container.src);
                this.renderReplacedElement(container, curves, image);
            } catch (e) {
                this.context.logger.error(`Error loading image ${container.src}`);
            }
        }

        if (container instanceof CanvasElementContainer) {
            this.renderReplacedElement(container, curves, container.canvas);
        }

        if (container instanceof SVGElementContainer) {
            try {
                const image = await this.context.cache.match(container.svg);
                this.renderReplacedElement(container, curves, image);
            } catch (e) {
                this.context.logger.error(`Error loading svg ${container.svg.substring(0, 255)}`);
            }
        }
        ...
        ...

그리드를 레이아웃안에서 유저가 크기 조절 가능하도록 만들고싶을 때 사용할 수 있는 라이브러리

사용 예시

공식 문서

공식 홈페이지 깃헙 코드

사용 방법

설치

npm install react-grid-layout

최상위 폴더에서 css 파일 임포트

// index.js
import "/node_modules/react-grid-layout/css/styles.css";
import "/node_modules/react-resizable/css/styles.css";

GridLayout

정해진 크기 내에서 레이아웃을 만들 수 있는 컴포넌트

layout

GridLayout 컴포넌트에는 layout이라는 props가 있다. 해당 데이터는 GridLayout에 들어갈 개별 요소들의 성질을 각각 객체에 담아 배열 형식으로 만든 것이다.

const layout = [
  { i: "a", x: 0, y: 0, w: 1, h: 2, static: true },
  { i: "b", x: 1, y: 0, w: 3, h: 2, minW: 2, maxW: 4 },
  { i: "c", x: 4, y: 0, w: 1, h: 2 },
];

속성값

static이 false인 경우 isDraggable : false , isResizable : false 로 설정값과 상관없이 덮어쓰기 된다.

예시 코드

import GridLayout from "react-grid-layout";
import "./App.css";

function App() {
  const layout = [
    { i: "a", x: 0, y: 0, w: 1, h: 2, static: true },
    { i: "b", x: 1, y: 0, w: 3, h: 2, minW: 2, maxW: 4 },
    { i: "c", x: 4, y: 0, w: 1, h: 2 },
  ];
  return (
    <div id="container">
      <GridLayout
        className="layout"
        layout={layout}
        cols={12}
        rowHeight={30}
        width={1200}
      >
        <div key="a">a</div>
        <div key="b">b</div>
        <div key="c">c</div>
      </GridLayout>
    </div>
  );
}

export default App;

다른 props 들을 살펴보면 다음과 같다. cols : 몇개의 열로 레이아웃을 구성할 지 정한다. rowHeight : 한 행의 높이를 지정할 수 있다. width : 레이아웃 전체의 넓이를 지정한다.

실행 화면

실행 화면에서 보이다싶이 GridLayout의 문제점은 레이아웃의 넓이가 고정되어있어 반응형을 고려하지 못한다는 것이다. 이를 보완하기 위해 반응형 레이아웃을 제공한다.

ResponsiveGridLayout

layouts

 const LAYOUTS = {
    lg: [
      { i: "a", x: 0, y: 0, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "b", x: 1, y: 0, w: 1, h: 2, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "c", x: 2, y: 0, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
    ],
    md: [
      { i: "a", x: 0, y: 0, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "b", x: 1, y: 0, w: 1, h: 2, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "c", x: 0, y: 1, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
    ],
  };

반응형 레이아웃에서는 사이즈별 아이템의 위치를 지정할 수 있기 때문에 사이즈를 키로 한 객체를 layout props 값으로 넘겨준다.

예시 코드

import "./App.css";
import { Responsive, WidthProvider } from "react-grid-layout";

const ResponsiveGridLayout = WidthProvider(Responsive);

function App() {
  const LAYOUTS = {
    lg: [
      { i: "a", x: 0, y: 0, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "b", x: 1, y: 0, w: 1, h: 2, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "c", x: 2, y: 0, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
    ],
    md: [
      { i: "a", x: 0, y: 0, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "b", x: 1, y: 0, w: 1, h: 2, minW: 1, maxW: 1, minH: 1, maxH: 2 },
      { i: "c", x: 0, y: 1, w: 1, h: 1, minW: 1, maxW: 1, minH: 1, maxH: 2 },
    ],
  };
  return (
    <div>
      <ResponsiveGridLayout
        className="layout"
        layouts={LAYOUTS}
        breakpoints={{ lg: 1000, md: 600 }}
        cols={{ lg: 3, md: 2 }}
      >
        {LAYOUTS.lg.map((el) => (
          <div key={el.i} {...el}>
            <h1>영화 🎬</h1>
            <p>
              세상에 이렇게 행복한 일이 있었나? 나는 잘 모르겠다.
              가나다라마바사가바나ㅏㄹ어니ㅏㅇ러니ㅏ러니ㅏ어ㅣ라넝리ㅏ너ㅣ아ㅓㄹ니아러ㅣㄴ아러니아러니ㅏ어린아ㅓ린아ㅓ리나ㅓㅇ리아ㅓ리나어리나.
            </p>
          </div>
        ))}
      </ResponsiveGridLayout>
    </div>
  );
}

export default App;

기본 GridLayout과 같은 형식이지만 breakpoint 지정을 통해 반응형 넓이에 따라 행의 수가 바뀌도록 지정해줄 수 있다.

breakpoints={{ lg: 1200, md: 996, sm: 768, xs: 480, xxs: 0 }}
cols={{ lg: 12, md: 10, sm: 6, xs: 4, xxs: 2 }}

라이브러리를 사용하면서 생긴 궁금증

어떻게 breakpoint가 변경됨을 인식하고 레이아웃을 변경할까?

// react-grid-layout/lib/ResponsiveReactGridLayout.jsx

  componentDidUpdate(prevProps: Props<*>) {
    // Allow parent to set width or breakpoint directly.
    if (
      this.props.width != prevProps.width ||
      this.props.breakpoint !== prevProps.breakpoint ||
      !isEqual(this.props.breakpoints, prevProps.breakpoints) ||
      !isEqual(this.props.cols, prevProps.cols)
    ) {
      this.onWidthChange(prevProps);
    }
  }

componentDidUpdate는 변동사항이 생기는 경우, Update 이전의 상태값을 props로 넘겨준다. 따라서 넓이가 조정되는 경우, 넓이를 다시 계산하는 함수를 실행하도록 해두었다.

  /**
   * When the width changes work through breakpoints and reset state with the new width & breakpoint.
   * Width changes are necessary to figure out the widget widths.
   */
// 넓이 변경 함수
  onWidthChange(prevProps: Props<*>) {
    const { breakpoints, cols, layouts, compactType } = this.props;
    // 현재 넓이에 따른 breakpoint 찾기
    const newBreakpoint =
      this.props.breakpoint ||
      getBreakpointFromWidth(this.props.breakpoints, this.props.width);

    // 이전 breakpoint
    const lastBreakpoint = this.state.breakpoint;

    // 새로운 breakpoint에 따른 행 갯수
    const newCols: number = getColsFromBreakpoint(newBreakpoint, cols);

    // 레이아웃 객체
    const newLayouts = { ...layouts };

    // Breakpoint 변경된 경우
    if (
      lastBreakpoint !== newBreakpoint ||
      prevProps.breakpoints !== breakpoints ||
      prevProps.cols !== cols
    ) {
      // 만약 최근 레이아웃에 대한 내용이 새로운 레이아웃 객체에 없는 경우를 대비해 레이아웃 클론
      if (!(lastBreakpoint in newLayouts))
        newLayouts[lastBreakpoint] = cloneLayout(this.state.layout);

      // Find or generate a new layout.
      let layout = findOrGenerateResponsiveLayout(
        newLayouts,
        breakpoints,
        newBreakpoint,
        lastBreakpoint,
        newCols,
        compactType
      );

      // This adds missing items.
      layout = synchronizeLayoutWithChildren(
        layout,
        this.props.children,
        newCols,
        compactType,
        this.props.allowOverlap
      );

      // Store the new layout.
      newLayouts[newBreakpoint] = layout;

      // callbacks - 레이아웃 변경에 따른 콜백 실행
      this.props.onLayoutChange(layout, newLayouts);
      this.props.onBreakpointChange(newBreakpoint, newCols);

      this.setState({
        breakpoint: newBreakpoint,
        layout: layout,
        cols: newCols
      });
    }

    const margin = getIndentationValue(this.props.margin, newBreakpoint);
    const containerPadding = getIndentationValue(
      this.props.containerPadding,
      newBreakpoint
    );

    // breakpoint가 아니라 width가 변경된 경우에도 실행되도록 
    // 이러면 재귀가 되지 않나..?🤔
    this.props.onWidthChange(
      this.props.width,
      margin,
      newCols,
      containerPadding
    );
  }