느낀점

전반적으로 우리가 사용하는 기술들의 이론적인 내용까지 깊게 탐구해볼 수 있는 과제가 많이 나왔고, 다양한 자료구조를 어떻게 활용할 수 있는지 고민할 수 있는 과제가 많이 나온 것 같다. 과제를 하나씩 해결하면서, 각각의 자료구조에 깊게 탐구하고, Javascript에서는 어떻게 구현되어 있었는지 깊게 리서치 해보는 시간을 가질 수 있었던 것 같다. 또한 막히는 것이 있을 때, 수료생의 관점 영상과 다른 동료분들의 코드를 보면서 실마리를 얻을 수 있었던 것 같다.

🌱 해당 포스트는 한 입 크기로 잘라먹는 타입스크립트(TypeScript)을 수강하고 정리한 글입니다.

타입스크립트란?

자바스크립트를 더 안전하게 사용할 수 있도록 타입 관련 기능을 추가한 언어로, 자바스크립트의 확장판이라 볼수 있다.

node.js(자바스크립트의 런타임 즉 실행 환경)의 등장으로, 자바스크립트가 다양한 프로그램(서버, 모바일 앱, 데스크탑 앱)을 개발하는데 사용할 수 있게 되었다.

하지만 이런 프로그램을 개발할 때 JS의 유연함이 오히려 독이 되었고, 엄격한 문법을 통해 안정성이 보장되어야할 필요성이 생겼다. 그래서 자바스크립트를 더 안전하게 사용할 수 있도록 타입에 관련된 여러가지 기능을 추가한, Typescript가 등장하게 되었다.

타입 시스템

모든 프로그래밍 언어에는, 사용할때 타입과 관련해서 지켜야 하는 규칙들을 모아둔 체계인 타입 시스템이 갖추어져 있다. 타입 시스템은 아래와 같은 내용들을 정의한다.

• 값들을 어떤 기준으로 묶어 타입을 규정할지

• 코드의 타입을 언제 검사할지
• 어떻게 타입을 검사할지?

타입 시스템은 크게 두 가지가 있다. 정적 타입 시스템과 동적 타입 시스템이다.

정적 타입 시스템

코드 실행 이전에 모든 변수의 타입을 고정적으로 결정한다. ex) C, Java 단점은, 모든 변수에 다 타입을 정의해야 해서, 타이핑 양과 코드량이 증가한다.

동적 타입 시스템

코드가 실행 되는 도중에 타입을 결정한다. 따라서 아래와 같은 특징을 가질 수 있다.

• 우리가 미리 변수에 타입을 설정하지 않아도 된다.

• 변수의 타입이 어떤 하나의 타입으로 딱 고정되지 않고, 현재 변수에 담긴 값에 따라서 변수의 타입이 동적으로 달라진다.

ex) Javascript, Python

단점은, 아래 보이는 것과 같이 타입이 달라 사용할 수 없는 메소드가 있는 경우, 실행전에는 에러가 나지 않지만, 실행했을 때 에러가 난다.

실행되었을 때 에러가나면, 프로그램이 비정상적으로 종료되는데, 실제 서비스에서 이런 오류가 나면, 서비스 전체가 셧다운 된다는 말과 동일하다. ⇒ 매우 치명적 😦

점진적 타입 시스템 (Gradual Type System)

JS의 장점을 살릴 수 있도록, 정적 타입 시스템과 같이 모든 변수의 타입을 지정할 필요는 없지만, 안정성있는 타입 시스템이 필요하다. 이에 Typescript는 동적 타입 시스템과 정적 타입 시스템을 혼합한 것 같은 점진적 타입 시스템(gradual Type System)을 채택했다.

위 그림과 같이, 타입스크립트에서는 모든 변수에 타입을 지정해줄 필요가 없다. 타입스크립트가 변수에 담기는 초기값을 기준으로, 변수의 타입을 알아서 추론해준다. 따라서, 정적 타입 시스템의 귀찮음과 동적 타입 시스템의 타입 불안전성 문제를 해결한다.

정리

타입스크립트의 동작 원리

대부분의 프로그래밍 언어는 프로그래밍 언어로 사람이 작성한 코드를 컴파일러를 통해 기계어(바이트코드)로 변환하는 작업을 거친다.

정확히 말하면, 코드 → AST(추상 문법 트리) → 바이트 코드 (기계어) 단계를 거친다. AST 과정? - 코드 실행에 관계없는 요소(코드의 공백이나 주석 탭 등)들은 전부 제거하고, 트리 형태의 자료구조에 코드를 쪼개서 저장해 놓는 과정

타입스크립트 동작과정

타입스크립트도 위의 컴파일 과정과 유사한 과정을 통해 컴파일 된다.

1. 코드가 AST로 변환된다.
2. 만들어진 AST를 보고, 코드 상에 타입 오류가 없는지 검사한다 (타입 검사)
3. 통과하면 AST를 (기계어가 아닌) Javascript로 변환한다.

즉, 타입스크립트 코드를 컴파일 해서 생성한, 자바스크립트 코드는 타입 검사를 통과한 자바스크립트 코드 이므로, 타입 오류가 발생할 가능성이 낮은 안전한 자바스크립트 코드이다.

최종 실행 과정

Typescript 실행 환경 설정

1. 타입스크립트를 Node.js에서 실행할 수 있다.
2. Node.js 내장 기능들의 타입 정보를 제공하는 @types/node 를 설치한다.
3. 타입스크립트 컴파일러(tsc)를 설치한다. typescript를 npm으로 설치하면, 해당 패키지에 동봉되어 있다. (tsc를 통해 ts 파일을 컴파일 하면 js 파일이 생성된다.)
4. 생성된 js 파일을 node로 실행한다.

❗️ tsc + node를 한번에 하기 위한 도구 tsx가 있다.

타입스크립트 컴파일 옵션 설정

*Typescript를 컴파일하고자 할 때, 엄격한 정도, 컴파일 결과 생성되는 JS의 버전 등을 설정할 수 있게 만들어주는 옵션 *

컴파일러 옵션은 패키지 루트 폴더에, tsconfig.json이라는 파일에 설정할 수 있다. 아래 명령어를 통해 생성할 수 있다.

tsc --init

옵션 예시

include 옵션

tsc에게 컴파일 할 타입스크립트 파일의 범위와 위치를 알려주는 옵션이다.

{
  "include": ["src"]
}

위처럼 설정하면, src 폴더 아래 모든 타입스크립트 파일이 한번에 컴파일된다.

Typescript를 Javascript로 변환하는 과정이나, type 검사 등에 대한 아주 상세한 옵션들을 설정할 때 사용

target 옵션

컴파일 된 javascript 코드의 버전을 설정한다.

타입스크립트 컴파일러의 동작 방식을 세부적으로 설정하기 위해 사용하는 기본 설정 파일은 무엇인가요? tsconfig.json 파일은 타입스크립트 컴파일러(tsc)에게 어떤 파일을 컴파일할지, 어떤 자바스크립트 버전으로 만들지 등을 알려주는 역할을 해요.

{
  "compilerOptions": {
    "target": "ES5"
  },
  "include": ["src"]
}

module 옵션

변환되는 자바스크립트 코드의 모듈 시스템을 설정할 수 있는 옵션이다.

{
  "compilerOptions": {
    "target": "ESNext",
        "module": "CommonJS"
  },
  "include": ["src"]
}

아래 코드를 컴파일한다고 할 때, 각 설정 옵션에 따라 결과가 달라진다.

// hello.ts
export const hello = () => {
  console.log("hello");
};

// index.ts
import { hello } from "./hello";
console.log(hello);

CommonJs

아래와 유사하게 컴파일 된다.

ES 모듈시스템

아래와 유사하게 컴파일 된다.

outDir 옵션

컴파일 결과 생성할 자바스크립트 코드의 위치를 결정한다.

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "outDir": "dist"
  },
  "include": ["src"]
}

outDir 옵션을 이용하면, 컴파일 결과로 생성되는 코드를 우리가 작성하는 코드 영역에서 분리할 수 있다.

strict 옵션

타입스크립트 컴파일러의 타입 검사 엄격함의 수준을 정하는 옵션이다.

{
  "compilerOptions": {
    ...
    "strict": true // 이렇게 설정하면 타입을 지정하지 않은 함수 매개변수에는 에러가 난다.
  },
  "include": ["src"]
}

export const hello = (message) => {
  console.log("hello " + message);
};

위 코드는 "strict": true일 때, 에러가 발생한다. ts는 함수 매개변수에 타입을 지정하도록 권장한다. 왜냐하면, 함수 매개변수의 경우 타입을 자동으로 추론할 수 없기 때문이다.

moduleDetection 옵션

타입스크립트의 모든 파일은 기본적으로 전역 파일(모듈)로 취급한다. 따라서 아래 상황에서 에러가 발생한다.

// a.ts

const a = 1; // ❌

// b.ts

const a = 1; // ❌

이 때, 두 가지 해결 방법이 있다.

1. export, import 키워드 활용

예시) 파일에 export {} 구문을 넣는다.

2. moduleDetection -> force

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "outDir": "dist",
        "moduleDetection": "force"
  },
  "include": ["src"]
}

moduleDetection을 force로 설정하면, 자동으로 모든 타입스크립트 파일이 로컬 모듈(독립 모듈)로 취급된다. 컴파일 결과인 js 코드를 확인해보면 export {} 구문이 자동으로 들어간 것을 확인할 수 있다.

🌱 해당 포스트는 한 입 크기로 잘라먹는 Next.js(v15)을 수강하고, Next.js 공식 문서 - page router를 참고하여 정리한 글입니다.

들어가며

기존의 SSR(서버 사이트 렌더링)의 경우, 사전 렌더링 과정에서 데이터가 필요하다면 fetching해 오는데, 시간이 오래 걸리면 응답이 느려진다는 단점이 있었다. 이런 단점을 해결할 수 있는 게 바로 SSG 렌더링 방식이다. SSG 방식에서는 접속 요청이 들어왔을 때가 아닌, 빌드 타임에 페이지를 미리 사전 렌더링 해둠으로써, 문제를 해결한다. Next.js 프로젝트에서는 npm run build 시 사전 렌더링을 진행하게 된다. 데이터 요청도 서버가 가동되기 이전인 빌드 타임에만 일어나기 때문에, 빌드 타임 이후에 발생하는 접속 요청들에 대해서는 굉장히 빠른 속도로 응답할 수 있다.

Static Site Generation (SSG, 정적 사이트 생성)

작동 방식

SSG는 빌드 타임에 사전 렌더링을 하여 페이지를 미리 생성하고, 이후에는 더 이상 새롭게 페이지를 생성하지 않는다. 따라서, 사용자의 접속 요청이 있을 때마다, 같은 페이지를 반환한다.

장점

사전 렌더링에 많은 시간이 소요되더라도, 이후 사용자 요청에 빠르게 응답 가능하다.

단점

SSG 방식은 빌드 타임 이후에는 사전 렌더링을 하지 않기 때문에, 매번 똑같은 페이지를 응답한다. [상황별 적합 여부]

• 최신 데이터가 빠르게 반영되어야 하는 페이지 (❌)
• 데이터가 자주 업데이트 되지 않는 정적 페이지 (✅)

SSG 사용법

정적 경로에 SSG 적용하기

// SSG 방식으로 작동
export const getStaticProps = async (context: GetStaticPropsContext) => {
  const [allBooks, recoBooks] = await Promise.all([
    fetchBooks(),
    fetchRandomBooks(),
  ]);

  return {
    props: {
      allBooks,
      recoBooks,
    },
  };
};

SSG로 데이터를 fetching 해오기 위해서, getStaticProps 함수를 사용하면 된다. getStaticProps 함수가 있으면, SSG로 동작한다. context의 타입은 GetStaticPropsContext이다.

// props의 타입 살펴보기
export default function Home({
  allBooks,
  recoBooks,
}: InferGetStaticPropsType<typeof getStaticProps>) {
  return (
    <div className={style.container}>
      <section>
        <h3>지금 추천하는 모든 도서</h3>
        {recoBooks.map((book) => (
          <BookItem key={book.id} {...book} />
        ))}
      </section>
      <section>
        <h3>등록된 모든 도서</h3>
        {allBooks.map((book) => (
          <BookItem key={book.id} {...book} />
        ))}
      </section>
    </div>
  );
}

props의 타입은 InferGetStaticPropsType<typeof getStaticProps>이 된다.

SSG 적용이 불가능한 경우) 쿼리 스트링이 필요한 경우

Next.js - getStaticProps API 공식문서를 살펴보면, getStaticProps 함수의 인자로 주어지는 context 안에 query가 없는 것을 확인할 수 있다. 사실, 빌드 타임에 query string을 알 수가 없는 것이 당연하기 때문에, context 안에 query가 없는 것은 합리적이다. 따라서 쿼리 스트링을 필요로 하는 search 페이지 같은 경우는 SSG 방식으로 동작시킬 수가 없다. 엄밀히 말하면, 검색 결과를 서버로부터 불러오는 동작은 수행할 수 없다.

만약 SSG로 search 페이지를 동작시키고 싶다면, SSG+CSR로 구현해야한다.

현재 쿼리 스트링을 꺼내와서 해당 값을 기준으로 검색 결과 데이터를 불러오는 과정을 사전 렌더링 이후에 컴포넌트 페이지 역할을 하는 컴포넌트에서 직접 진행해야 한다 (기존 react CSR). 이를 구현하는 방법은 간단하다. useRouter 훅을 사용하여 쿼리 스트링을 받아오고, useEffect를 사용하여 데이터 페칭을 하며, 데이터는 useState를 통해 관리하면 된다..

따라서 사전 렌더링 과정에서는, 결국 이 페이지의 레이아웃(div 태그 정도만) 정도만 렌더링하게 된다. 그 후, 클라이언트 사이드 측에서 이 컴포넌트가 다시 실행되면서, 직접 쿼리 스트링으로 검색어를 불러와서 검색 결과 데이터를 클라이언트 사이드 측에서 렌더링하게 된다.

search 페이지를 들어가보면, 검색 결과 데이터는 제외하고 나머지 부분만 렌더링해서 브라우저에게 보내주는 것을 확인할 수 있다.

동적 경로에 SSG 적용하기

동적인 경로에 대해서 SSG를 적용하고 싶다면, 반드시 getStaticPaths를 통해 어떤 url 파라미터가 존재할 수 있는지, 즉 어떤 경로가 존재할 수 있는지 알아야 한다.

getStaticPaths를 사용하지 않고 동적 경로에 SSG를 적용하려고 하면 아래와 같은 에러가 뜬다.

경로를 설정하게 되면, 가능한 경로에 대한 html을 모두 생성하게 된다.

getStaticPaths 사용법

export const getStaticPaths = () => {
  return {
    // paths라는 속성으로 어떤 경로가 존재할 수 있는지를 배열로 반환
    paths: [
      {
        // 가능한 경로를 params라는 속성에 적어주면 된다.
        params: {
          // 파라미터 이름 : 값
          // 파라미터 값은 반드시 문자열로 작성해야지 정상 작동한다.
          id: "1",
        },
      },
      { params: { id: "2" } },
      { params: { id: "3" } },
    ],
    // fallback은 예외 상황에 대비하는 옵션
    // 존재하지 않는 url에 어떻게 대응할 것인지의 옵션
    fallback: false, // not found를 반환함
  };
};

가능한 경로를 paths 속성에 배열로 반환한다. 배열에는 {params : {[파라미터 이름] : 문자열 경로 값}} 을 작성한다. fallback 옵션을 반드시 넣어주어야 한다. fallback 옵션은 존재하지 않는 url에 어떻게 대응할 것인지의 옵션으로 기본은 false이다. false 이면, 404.tsx(not found) 페이지를 반환한다.

fallback 옵션

fallback 옵션은 존재하지 않는 url에 대해 어떻게 대응해줄 것인지를 결정해준다.

• fallback: false : 404 Not Found 페이지를 반환한다.

• fallback: "blocking" : 매칭되지 않았던 경로의 페이지를 즉시 생성한다. (SSR 처럼)
• fallback: true : 매칭되지 않았던 경로의 페이지를 즉시 생성하되, 페이지만 미리 반환하고, props를 후속으로 보내준다.

fallback: false

404 Not Found 페이지를 반환한다.

fallback: "blocking"

SSR 방식처럼 실시간으로 요청받은 페이지를 사전 렌더링 해서 브라우저에게 반환해준다. 따라서, blocking 옵션을 이용하면 빌드 타임에 사전에 생성해 두지 않았던 페이지까지 사용자에게 제공해줄수 있다는 장점이 있다.

이후 접속 요청이 들어와 생성된 페이지는 서버에 자동으로 저장된다.

fallback: true

fallback: "blocking" 방식을 사용하여, 존재하지 않았던 페이지를 SSR 방식으로 새롭게 생성할 때, 만약 백엔드 서버로의 추가적인 데이터를 요청 등으로 인해 페이지의 생성 시간(사전 렌더링)이 길어지면 서버가 응답을 아무것도 하지 않기 때문에 문제가 발생할 수 있다. 이런 문제를 해결할 수 있는 방법이 fallback: true 옵션이다. 이 방식은, fallback: "blocking" 처럼, 존재하지 않았던 페이지를 SSR 방식으로 새롭게 생성하지만, props가 없는 상태로 페이지를 반환하고(사실상 레이아웃이 그려진다), 이후에 props를 전달해주는 방식으로 페이지를 렌더링 한다.

✨ 여기서 의미하는 Props란? 페이지에 필요한 데이터를 가져오는 getStaticProps 함수가 페이지 컴포넌트에 전달해주는 props

예시

export const getStaticPaths = () => {
  return {
    // paths라는 속성으로 어떤 경로가 존재할 수 있는지를 배열로 반환
    paths: [
      { params: { id: "1" } },
      { params: { id: "2" } },
      { params: { id: "3" } },
    ],
    // fallback: false, // not found를 반환함
    // fallback: "blocking",
    fallback: true,
  };
};

export const getStaticProps = async (context: GetStaticPropsContext) => {
  const id = context.params!.id;
  const book = await fetchOneBook(Number(id));
  return { props: { book } };
};

export default function Book({
  book,
}: InferGetStaticPropsType<typeof getStaticProps>) {
  if (!book) {
    return "문제가 발생했습니다. 다시 시도해주세요";
  }

  const { id, title, subTitle, description, author, publisher, coverImgUrl } =
    book;

  return (
    <div className={style.container}>
     /* 코드 생략 */
    </div>
  );
}

위 코드에서 보면, fallback: "blocking" 으로 옵션을 주었기 때문에, 초기 접속시 props가 전달되지 않아,

 if (!book) {
    return "문제가 발생했습니다. 다시 시도해주세요";
  }

부분이 렌더링 되었다.

그리고 이후에 props를 json파일으로 받아 렌더링한다.

💡 내 생각 페이지 생성이 모든 초기 접속에 대해 새로 생성하는 것이 아닌 next 서버 기준 완전 초기에만 페이지를 생성하고, 그 다음부터는 .next에 페이지를 저장하고 그 페이지를 내려보내주는 것 같다.

fallback: true 에서 fallback 상태 예외 처리

✨ fallback 상태란? 페이지 컴포넌트가 아직 서버로부터 데이터(getStaticProps에서의 props)를 전달 받지 못한 상태를 말한다.

현재 예시 코드에서 fallback 상태에 있으면, if(!book) 구문에 걸려 "문제가 발생했습니다."로 뜨게 된다. 아직 로딩 중인 건데, "오류가 발생해서 데이터가 안뜨는 거구나" 라고 사용자가 오해할 수 있다. 따라서 제대로 된 상태를 표시할 필요가 있다.

그렇다고, 현재 코드의 텍스트를 if(!book) 구문에 걸려 "로딩중입니다." 라 바꿔버리면, 실제로 데이터를 가져오는데 오류가 뜬 상황에서도 "로딩중입니다."이라고 뜨기 때문에 문제가 있다.

따라서 fallback 상태에서만 보여주는 UI가 필요하다

export default function Book({
  book,
}: InferGetStaticPropsType<typeof getStaticProps>) {
  const router = useRouter();

  // fallback 상태에 해당할때만 보여지는 ui
  if (router.isFallback) return "로딩중";

/* ...코드 생략... */

props 데이터가 없는 경우, Not Found 반환

export const getStaticProps = async (context: GetStaticPropsContext) => {
  const id = context.params!.id;
  const book = await fetchOneBook(Number(id));

  if (!book) {
    return {
      notFound: true,
    };
  }

  return { props: { book } };
};

getStaticProps의 props가 없는 경우,{notFound: true}를 리턴하여, Not Found 페이지를 반환할 수 있다.

빌드 결과 살펴보기

먼저, getStaticPaths 로 설정해준 것과 같이, id가 1, 2, 3에 대한 경로의 페이지(html)이 생성된 것을 볼 수 있다.

● (SSG) prerendered as static HTML (uses getStaticProps)

이 페이지가 SSG 방식으로 동작. HTML로 사전 렌더링된 페이지 (getStaticProps를 사용해서 데이터를 불러오는 static 페이지를 의미)

ƒ (Dynamic) server-rendered on demand

동적(다이나믹) 페이지를 의미 -> 요청을 받을 때마다 사전 렌더링된다. or 실행된다. API routes도 ssr로 작동하도록 설정되어 있기 때문에 ƒ라고 쓰여있다.

○ (Static) prerendered as static content

SSG와 동일한 정적 페이지지만, getStaticProps를 설정하지 않음. 기본 값으로 설정된 SSG를 의미한다. => next.js 에서는 아무것도 설정하지 않은 페이지들을 기본값으로 정적인 페이지로 빌드타임에 미리 사전 렌더링한다.

코드

• 2.16) SSG 4. 폴백옵션 설정하기

✨ 결론

SSG는 빌드 타임에 페이지를 미리 사전 렌더링해 둠으로써, 사용자 요청 시 빠르게 응답할 수 있는 렌더링 방식이다.

• 장점은 사전 렌더링이 오래걸려도, 실제 접속 요청엔 빠르게 응답 가능하다는 것
• 단점은 매번 똑같은 페이지만 응답하기 때문에, 최신 데이터 반영은 어렵다.
• Next.js에서는 기본적으로 next.js는 SSG로 사전 렌더링한다.

적용 방법

1) 데이터 페칭이 필요한 경우 getStaticProps 함수를 사용하면 된다. 2) 동적 경로에서, SSG를 적용하고 싶은 경우 getStaticPath 함수를 사용해서, 가능한 모든 경로에 대한 정적 페이지를 생성할 수 있다. 3) 만약 대응하지 못한 동적 경로가 있다면, fallback 옵션 값을 어떻게 하느냐에 따라 다르게 대응할 수 있다.

• fallback: false ** : 404 not found를 반환함**
• fallback: "blocking"** : SSR 방식으로 페이지 생성**
• fallback: true** : SSR 방식 + 데이터가 없는 폴백 상태의 페이지부터 반환**

레퍼런스

• Next.js 공식 문서 - Static Site Generation (SSG)
• getStaticProps API
• getStaticPaths API

🌱 해당 포스트는 한 입 크기로 잘라먹는 Next.js(v15)을 수강하고, Next.js 공식 문서 - page router를 참고하여 정리한 글입니다.

사전 렌더링 방식

Next.js에서는 다양한 사전 렌더링 방식을 제공한다. 이번 포스트에서는 Page Router에서 서버 사이드 렌더링(SSR) 방식을 어떻게 구현할 수 있는지에 대해 알아보려고 한다.

서버 사이드 렌더링 (SSR)

만약 페이지가 서버 사이드 렌더링(SSR) 을 사용한다면, 해당 페이지의 HTML은 매 요청마다 생성된다. 페이지를 SSR로 만들고 싶다면, getServerSideProps 함수를 사용한다. 이는 Next.js 프레임워크의 일종의 문법으로 받아들일 수 있다.

getServerSideProps 함수

getServerSideProps 함수는 컴포넌트보다 먼저 실행되어서, 컴포넌트에 필요한 데이터를 불러오는 함수이다. getServerSideProps 함수를 만들어 주기만 하면, 해당 페이지는 SSR로 사전 렌더링을 진행한다.

❗️ getServerSideProps 함수는 사전 렌더링 과정에서 서버 측에서만 딱 한번 실행된다. 따라서 getServerSideProps 함수에서 console.log()를 실행하면, 해당 출력은 next 서버에서만 보이고, 브라우저에서는 보이지 않는다.

export default function Page({ data }) {
  // Render data...
}

// This gets called on every request
export async function getServerSideProps() {
  // Fetch data from external API
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // Pass data to the page via props
  return { props: { data } }
}

getServerSideProps는 리턴 값으로 반드시 props라는 property를 포함하는 객체를 반환해야한다. 이때 props 객체가 컴포넌트의 props로 들어가게 되고, 컴포넌트에서 사용할 수 있게 된다.

예시 코드

// src/pages/index.tsx
import SearchableLayout from "@/components/searchable-layout";
import { ReactElement } from "react";
/* import 구문 생략 */

// ⭐️ getServerSideProps 함수를 만들어 주기만 하면, 해당 페이지는 SSR로 사전 렌더링을 진행한다.
// "/" 경로로 접속해 index 페이지를 요청받아 사전 렌더링을 진행할 때, Home 컴포넌트보다 먼저 실행된다.
// 그래서 index 페이지에 필요한 데이터를 불러오는 기능(ex. 다른 백엔드 서버로부터 데이터 페칭)을 제공한다.
export const getServerSideProps = () => {
  // 컴포넌트보다 먼저 실행되어서, 컴포넌트에 필요한 데이터를 불러오는 함수
  const data = "hello";
  return { props: { data } };
};

export default function Home({data}: any) {
  console.log(data);
  return (
    <div className={style.container}>
      /* 코드 생략 */
    </div>
  );
}

아래 console의 log는 위 예시 코드를 실행한 결과이다.

실행 과정

getServerSideProps 는 사전 렌더링 과정에서 한 번 실행된다. Home 컴포넌트의 경우, 사전 렌더링 시 한 번 실행되고, 클라이언트에서 hydration을 위해 한 번 실행된다. (총 두 번 실행) 따라서 컴포넌트에서도 클라이언트 API(window 객체 등)에 아무런 조건 없이 접근하면, 아래와 같이 에러가 난다.

❗️ 만약 브라우저 API를 사용해야 해서, 브라우저 측에서만 실행되는 코드를 작성하고 싶다면? 여러가지 방법이 있지만, 가장 쉬운 방법은 useEffect를 사용하는 것이다.

export default function Home({ data }: any) {
  // 컴포넌트 마운트 이후, 실행
  useEffect(() => {
    console.log(window);
  }, []);
  return (
    <div className={style.container}>
      /* 코드 생략 */
    </div>
  );
}

코드 실행 결과 (브라우저)

빌드 결과

ƒ  (Dynamic)  server-rendered on demand

getServerSideProps 함수를 사용하니까, 바로 페이지의 사전 렌더링 방식이 서버 사이드 렌더링(SSR) 으로 바뀐 것을 볼 수 있다. (꼭 getServersideProps 함수를 구현하지 않아도, 해당 함수가 있다면 SSR로 바뀐다)

getServerSideProps 함수 자세히 알아보기

+) getServerSideProps 로 받아오는 데이터의 type

Next.js에서 내장 타입을 제공하고 있다. InferGetServerSidePropsType<typeof getServerSideProps> 를 사용해서, props의 타입을 지정해줄 수 있다.

export default function Home({
  data,
}: InferGetServerSidePropsType<typeof getServerSideProps>) {

  return (
    <div className={style.container}>
      /* 코드 생략 */
    </div>
  );
}

🔍 getServerSideProps의 인자 값: context

getServerSideProps(context) 함수는 호출 시 context 객체를 인자로 받는다. context 객체의 타입은 Next.js 내장 타입인 GetServerSidePropsContext이다. ⇒ query가 필요할 때 사용하면 유용하다.

⚙️ getServerSideProps의 동작 방식

• getServerSideProps는 서버에서만 실행됩니다.

• 오직 페이지 컴포넌트에서만 export할 수 있습니다.
• 반환값은 JSON 형식입니다.
• 사용자가 해당 페이지에 접근하면, getServerSideProps가 호출되어 데이터를 가져오고, 그 데이터를 바탕으로 초기 HTML을 렌더링합니다.
• props로 전달된 값은 클라이언트에서도 초기 HTML 안에 포함되므로 민감한 정보는 절대 포함시키지 말아야 합니다.
• 사용자가 next/link나 next/router를 통해 페이지에 접근할 경우, Next.js는 서버에 API 요청을 보내고, 서버는 getServerSideProps를 실행합니다.
• getServerSideProps는 서버에서 실행되기 때문에, 별도의 API Route를 만들 필요 없이 CMS, 데이터베이스, 외부 API 등을 직접 호출할 수 있습니다.
• getServerSideProps 안에서 사용할 모듈은 파일 최상단에서 import할 수 있습니다.
• 이때 import한 모듈은 클라이언트에 번들링되지 않기 때문에 서버 전용 코드도 작성할 수 있습니다. ⇒ 즉, 데이터베이스 쿼리, 보안 토큰 처리 등 클라이언트에 노출되어선 안 되는 코드를 안전하게 작성할 수 있습니다.

❓ 초기 접속 이후, getServerSideProps이 있는 page에 방문한 경우?

초기 접속 이후에 페이지 이동이 발생하면, Client Side Rendering (CSR)로 작동하는데, 만약 해당 페이지가 getServerSideProps 함수를 포함하고 있다면 어떻게 될까? 해당 페이지의 JS 코드와 함께 getServerSideProps을 실행한 결과 (props)를 JSON 형식으로 전달해준다. ⇒ 관련 질문 링크🔗

코드

• 2.12) SSR 2. 실습

레퍼런스

• Next.js 공식 문서 - Server-side Rendering (SSR)
• getServerSideProps
• getServerSideProps API

🌱 해당 포스트는 한 입 크기로 잘라먹는 Next.js(v15)을 수강하고, Next.js 공식 문서 - page router를 참고하여 정리한 글입니다.

글로벌 레이아웃

next.js 앱의 모든 페이지에 다 일괄적으로 적용이 되는 글로벌 레이아웃을 설정할 수 있다. _app 컴포넌트에 공통적인 레이아웃을 만들어주면 된다. 하지만, 공통적인 레이아웃 로직이 많아지면, 코드 가독성이 떨어질 수 있으므로, 레이아웃 파트만 별도로 분리하여 컴포넌트를 만드는 것이 좋다.

src > components > global-layout.tsx라는 파일을 만들고, 이 파일 안에 글로벌 레이아웃을 만든다.

📁 파일 구조 설명

src/
├── components/
│   └── global-layout.tsx   ← 글로벌 레이아웃 컴포넌트
├── pages/
│   └── _app.tsx            ← 앱 전체에 글로벌 레이아웃 적용

글로벌 레이아웃 생성

// src/components/global-layout.tsx
import Link from "next/link";
import { ReactNode } from "react";
import style from "./global-layout.module.css";

export default function GlobalLayout({ children }: { children: ReactNode }) {
  return (
    <div className={style.container}>
      <header className={style.header}>
        <Link href="/">📚 ONEBITE BOOKS</Link>
      </header>
      <main className={style.main}>{children}</main>
      <footer className={style.footer}>제작 @grit03</footer>
    </div>
  );
}

_app 컴포넌트에 적용

// pages/_app.tsx

import GlobalLayout from '@/components/global-layout'
import type { AppProps } from 'next/app'
import '@/styles/globals.css' // 전역 스타일

export default function App({ Component, pageProps }: AppProps) {
  return (
    <GlobalLayout>
      <Component {...pageProps} />
    </GlobalLayout>
  )
}

특정 페이지를 위한 레이아웃

모든 페이지에 공통적으로 적용되는 레이아웃이 아닌, 특정 페이지에만 적용되는 레이아웃이 필요한 경우가 있다. 특정 페이지에만 적용할 수 있는 레이아웃은 아래와 같이 생성할 수 있다.

컴포넌트에 getLayout 함수를 추가해서, 페이지 별 레이아웃을 구현할 수 있다.

❶ 먼저, 페이지에 적용할 레이아웃을 만든다.

// src/components/searchable-layout.tsx
import { useRouter } from "next/router";
import { ReactNode, useEffect, useState } from "react";
import style from "@/components/searchable-layout.module.css";

export default function SearchableLayout({
  children,
}: {
  children: ReactNode;
}) {

  /*  코드 생략... */

  return (
    <div>
      <div className={style.searchbar_container}>
        <input
          value={search}
          onChange={onSearchChange}
          placeholder="검색어를 입력하세요..."
        />
        <button onClick={onSubmit}>검색</button>
      </div>
      {children}
    </div>
  );
}

❷ 레이아웃을 적용하고 싶은 페이지에 getLayout 함수를 속성으로 추가한다.

// src/pages/index.tsx
import SearchableLayout from "@/components/searchable-layout";
import { ReactElement, ReactNode } from "react";

export default function Home() {
  return (
    <div>
      <h1>메인 화면</h>
    </div>
  );
}

Home.getLayout = (page: ReactElement) => {
  return <SearchableLayout>{page}</SearchableLayout>;
};

❓ 어떻게 컴포넌트 함수에 속성을 추가할 수 있는 걸까? 자바스크립트의 모든 함수들은 사실 다 객체이다. 그렇기 때문에 함수에도 속성으로 또 다른 함수를 추가할 수 있다. 🔗 참고자료 : 객체 자료형 자세히 살펴보기

❸ _app.tsx에서 Component가 getLayout 함수 속성이 있는지를 확인하고, 있다면 해당 함수를 실행시켜, Layout을 적용한다.

// src/pages/_app.tsx
import "@/styles/globals.css";
import GlobalLayout from "@/components/global-layout";
import type { AppProps } from "next/app";
import { ReactElement, ReactNode } from "react";
import { NextPage } from "next";

// 기본적인 컴포넌트에는 getLayout함수가 없으므로, 타입에 추가해야한다.
type NextPageWithLayout = NextPage & {
  getLayout?: (page: ReactElement) => ReactNode;
};

// 컴포넌트를 getLayout이 옵셔널로 있는 타입으로 바꾼다.
type AppPropsWithLayout = AppProps & {
  Component: NextPageWithLayout;
};

export default function App({ Component, pageProps }: AppPropsWithLayout) {
  // 컴포넌트에 getLayout 함수가 있다면 사용하고, 없으면 그대로 page를 리턴
  const getLayout = Component.getLayout ?? ((page: ReactElement) => page);

  return <GlobalLayout>{getLayout(<Component {...pageProps} />)}</GlobalLayout>;
}

❓ ReactElement 와 ReactNode의 차이 ReactNode는 리액트에서 렌더링 가능한 모든 값 (React.createElement의 리턴 값 뿐만 아니라, string, number, null 등)을 말하며, ReactElement보다 포괄적인 의미이다.

❓ ** 타입 단언(type assertion)이란?** 타입 단언은 개발자가 해당 타입에 대해 확신이 있을 때 사용하는 타입 지정 방식으로, 타입스크립트의 타입 추론에 기대하지 않고 개발자가 직접 타입을 명시하여 해당 타입으로 강제하는 것을 의한다.

동일 구조를 Layout으로 구현했을 때의 장점

페이지 간 이동 시, 입력 값이나 스크롤 위치 등 페이지 상태를 유지하고 싶다면, Single-Page Application(SPA) 경험을 제공하는 것이 좋다. Layout 패턴을 사용하면, 공통된 부분은 React 컴포넌트 트리가 동일하기 때문에, Layout에 있는 값들이 페이지 전환 중에도 유지된다. 왜냐하면, React는 컴포넌트 트리가 유지되면, 상태(state) 값들을 보존해주기 때문이다.

🔗 관련 공식 react article

레퍼런스

• Next.js 공식문서-Pages and Layouts
• TS 객체 자료형
• 타입 단언
• [TypeScript] 타입 추론과 타입 단언
• ReactElement vs ReactNode vs JSX.Element

  코드 저장소(Github)

  레이아웃 적용

🌱 해당 포스트는 한 입 크기로 잘라먹는 Next.js(v15)을 수강하고, Next.js 공식 문서 - app router를 참고하여 정리한 글입니다.

Client Component

Client Component는 클릭 이벤트 등 사용자와 상호작용할 수 있는 컴포넌트다. Client Component는 서버에서 미리 렌더링된 후 (사전 렌더링 과정), 클라이언트에서도 JS 코드를 실행시켜 상호작용할 수 있게 만든다.

클라이언트 렌더링의 장점

• 상호작용: Client Components는 상태, 효과 및 이벤트 리스너를 사용할 수 있으므로 사용자에게 즉각적인 피드백을 제공하고 UI를 업데이트할 수 있다.

• 브라우저 API: Client Components는 geolocation이나 localStorage 와 같은 브라우저 API에 접근할 수 있다.

Client Component 사용하기

Next.js에서 Client Components를 사용하려면, 파일 상단에 "use client" 지시어를 import 위에 추가하면 된다.

// next.js 공식 문서 예시
'use client' // 이렇게 추가하면 된다.

import { useState } from 'react'

export default function Counter() {
  const [count, setCount] = useState(0)

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  )
}

여러 use client 진입점을 정의하는 경우:

React Component 트리에서 여러 "use client" 진입점을 정의할 수 있다. 하지만, 클라이언트에서 렌더링해야 하는 모든 컴포넌트에 "use client"를 정의할 필요는 없다. 한 번 경계를 정의하면 모든 자식 컴포넌트와 import된 모듈이 클라이언트 컴포넌트로 간주되기 때문이다.

Client Component 렌더링 방식

서버에서는 (사전 렌더링) :

1. React는 Server Components를 React Server Component Payload (RSC Payload)라는 특별한 데이터 형식으로 렌더링하며, 여기에는 Client Components에 대한 참조가 포함되어 있다.

2. Next.js는 RSC Payload와 Client Component JavaScript 코드를 사용하여 서버에서 경로에 대한 HTML을 렌더링한다.

그런 다음 클라이언트에서는:

1. 사전 렌더링 된 HTML을 사용하여 경로에 해당하는 페이지를 빠르게 보여준다. (상호작용 X)

2. React Server Components Payload를 사용하여 Client와 Server Component 트리를 조정하고 DOM을 업데이트합니다.

3. JavaScript 코드를 사용하여 Client Components를 Hydration하여, UI를 인터랙티브하게 만든다.

Hydration이란? Hydration은 이벤트 리스너를 DOM에 연결하여 정적 HTML을 인터랙티브하게 만드는 과정입니다. 하이드레이션은 hydrateRoot React API를 사용하여 백그라운드에서 수행됩니다.

초기 접속 이후의 네이게이팅

초기 접속 시에만, 사전 렌더링된 페이지를 보여주고, 이후 경로 이동이 발생하는 경우 Client Components가 서버 렌더링된 HTML 없이 클라이언트에서 렌더링 된다.

경로 이동이 발생하면, Client Component JavaScript 번들이 다운로드한다. 번들이 준비되면 React는 RSC Payload를 사용하여, Client와 Server Component 트리를 조정하고 DOM을 업데이트한다.

🌱 해당 포스트는 한 입 크기로 잘라먹는 Next.js(v15)을 수강하고, Next.js 공식 문서 - app router를 참고하여 정리한 글입니다.

서버 컴포넌트

React Server Components는 UI를 서버에서 렌더링하고 선택적으로 캐싱할 수 있는 기능을 제공한다. Next.js에서는 라우트(route)기준으로 나누어 렌더링한다. 렌더링 전략은 크게 세가지가 있다.

• Static Rendering (정적 렌더링)

• Dynamic Rendering (동적 렌더링)
• Streaming (스트리밍)

서버 컴포넌트 렌더링 과정

서버에서, Next.js는 React의 API를 사용하여 렌더링을 조정합니다. 렌더링 작업은 route(라우트) 세그먼트와 Suspense 경계로 나뉩니다.

각 청크는 두 단계로 렌더링됩니다.

📡 서버에서

1. [서버 컴포넌트 실행] React는 Server Components를 React Server Component Payload (RSC Payload) 라는 특별한 데이터 형식으로 렌더링합니다.

2. [클라이언트 컴포넌트 실행] Next.js는 RSC Payload와 Client Component JavaScript 코드를 사용하여 HTML을 서버에서 생성한다.

👩🏻‍💻 클라이언트에서

1. 전달 받은 사전 렌더링된 HTML을 보여준다. (FCP 개선)

2. 클라이언트로 RSC Payload 전달하여 사용한다. (서버 컴포넌트와 클라이언트 컴포넌트 트리를 연결하고, DOM을 업데이트 하기 위해서 필요) ⭐️ 더 알아보기

3.(클라이언트 컴포넌트의 경우) JavaScript 코드를 실행시켜 Client Components를 Hydration하여 애플리케이션을 인터렉션 가능하도록 변경한다.

서버 렌더링 전략

Static Rendering (정적 렌더링)

Next.js의 기본적인 렌더링 방식이다. 정적 렌더링을 사용하면, 경로(route)가 빌드 시간에 렌더되거나, 데이터 재검증이 끝났을 때 렌더된다.

정적 렌더링은 개인화된 페이지가 아닌, 사용자 구분 없이 같은 내용을 보여줘야할 때, 유용하다.

예시) 정적 블로그 게시물, 제품 페이지

Dynamic Rendering (동적 렌더링)

동적 렌더링은 사용자로부터 요청받았을 때, 경로(route)가 렌더링 된다.

동적 렌더링은 사용자마다 데이터가 달라 개인적인 페이지를 보여줘야하거나, 요청 시에만 알 수 있는 정보가 페이지에서 필요한 경우 유용하다. 예를 들어, 쿠키(cookie) 가 필요한 경우나 URL의 search params가 있는 경우가 있다.

동적 렌더링으로 동작하는 경우

Dynamic API의 사용 여부와, fetch 함수를 { cache: 'no-store' } 옵션과 함께 사용했는지 여부에 따라 동적 렌더링을 할지 정적 렌더링을 할지 결정한다.

어떤 렌더링으로 동작할지는 위 상황에 따라, Next.js가 가장 최적의 방식으로 자동 결정해주기 때문에, 이를 개발자가 고민할 필요는 없다.

동적 API란?

동적 API는 사전 렌더링 시점에는 알 수 없고, 요청 시점에만 알 수 있는 정보에 의존하는 API를 말한다. 이러한 API를 사용하면 개발자가 해당 경로를 요청 시점에서 동적으로 렌더링하겠다는 의도를 나타내는 것이며, 해당 경로 전체가 동적 렌더링으로 전환된다. 예시) cookies, headers, connection, draftMode, searchParams prop, unstable_noStore

Streaming (스트리밍)

스트리밍은 서버에서 UI를 청크로 나누어 클라이언트에 스트리밍할 수 있게 한다. 작업은 청크 단위로 나뉘어 준비가 되면 클라이언트에 스트리밍되며, 사용자가 페이지의 일부를 즉시 볼 수 있게 한다.

🌱 해당 포스트는 한 입 크기로 잘라먹는 Next.js(v15)을 수강하고, Next.js 공식 문서 - page router를 참고하여 정리한 글입니다.

Next.js의 Page Router란?

2025년 기준으로 Next.js는 두 가지 라우팅 방식을 제공한다. App router와 Page Router이다. Page Router가 먼저 등장한 라우터로, 현재 많은 기업에서 사용되고 있는 안정적인 라우터이다.

🚏 Routing (라우팅) 이란? 어떤 URL 요청이 왔을 때, 어떤 페이지(컴포넌트)를 보여줄지를 결정하는 규칙

Page Router 는 파일 시스템 기반으로 한 라우터를 제공한다. pages directory 안에 파일이 추가되면, 자동적으로 라우트가 된다.

경로(Route) 만들기

루트 경로를 위한 index.tsx

pages 폴더 아래에 있는 index.tsx 파일에 있는 컴포넌트가 /(루트 라우트)의 페이지로 렌더링된다.

경로 이름.tsx

이름.tsx 파일을 만들면, /이름 경로일 때 해당 컴포넌트를 페이지로 렌더링한다.

경로 파일 > index.tsx

원하는 경로 이름으로 폴더를 만들고, 그 안에 index.tsx 파일을 만들면, 폴더 이름으로 경로가 만들어지고, 해당 경로로 접속했을 때, index.tsx 파일을 페이지로 렌더링한다.

동적 경로(Dynamic Routes) 만들기

동적 경로(Dynamic Routes) 란 경로에 가변적인 값을 포함하고 있는 경우를 말한다. 여기서 가변적인 값들을 url 파라미터라고 부른다.

아래와 같이 URL의 일부가 변수처럼 바뀔 수 있는 구조를 말한다. /post/1 /post/2 /post/3

기본 동적 경로 생성

📁 파일 구조

/pages
  └── blog
       └── [id].tsx

🧠 의미

[id].tsx는 id라는 변수에 따라 다른 콘텐츠를 보여줌 → 마치 postId를 파라미터로 받는 느낌

🌐 매칭되는 URL 예시

/blog/1 /blog/hello-world /blog/42

🧾 코드 예시

// pages/blog/[id].tsx

import { useRouter } from 'next/router'

export default function BlogPost() {
  const router = useRouter();
  const { id } = router.query;

  return <h1>블로그 글 ID: {id}</h1>;
}

const { id } = router.query; 에서 router의 query 속성을 통해 값을 가져올 수 있다.

⚠️ 단, /blog/id 경로에만 대응된다. 따라서 /blog/123은 대응되지만, /blog/123/123은 대응되지 않는다.

catch all segments

[]만 사용하게 되면, /blog/123은 대응되지만, /blog/123/123은 대응되지 않는다. /blog/123/123와 같은 경로도 대응할 수 있는 범용적인 페이지를 만들고 싶다면, [id].tsx가 아닌 [...id].tsx로 만들어주면 된다.

📁 파일 구조

/pages
  └── blog
       └── [...id].tsx

🌐 매칭되는 URL 예시

🧾 코드 예시

// pages/blog/[...id].tsx

import { useRouter } from 'next/router'

export default function BlogPost() {
  const router = useRouter();
  const { id } = router.query;
  console.log(id); // '/blog/123/456'의 경우 ["123", "456"] 이렇게 배열로 출력

  return <h1>블로그 글</h1>;
}

배열 값으로 모든 url 파라미터 값이 나온다.

⚠️ 단, /blog와 같이 url 파라미터가 아예 없는 경우에는 대응되지 않는다. catch all segment는 /blog 뒤에 무슨 경로라도 나와야 매칭이 된다.

optional catch all segments

url 파라미터가 아예 없는 경우, catch all segment로 하면, index 경로에는 대응되지 않는다. 즉, /blog 페이지에는 대응되지 않는다는 의미이다. 만약에 정말 더 범용적으로 /blog 뒤에 어떤 경로가 나오든 다 대응하도록 하고 싶다면, 대괄호로 한번 더 감싸자!

📁 파일 구조

/pages
  └── blog
       └── [[...id]].tsx

🌐 매칭되는 URL 예시

404 페이지 만들기

특정 url에 대응되는 페이지가 없을 때 보여주기 위한 404 페이지는 아래와 같이 만들 수 있다.

/pages
  └── 404.tsx

✨ 정리

정적 경로 : 경로.tsx 혹은 경로 폴더 아래 index.tsx 동적 경로 : [id].tsx 범용적 경로 : [...id].tsx , [[...id]].tsx 없는 경로 (404 페이지) : 404.tsx

레퍼런스

• Pages and Layouts
• Dynamic Routes

• 인덱스로 접근 불가
• 중복 원소 없음
• 특정 값을 삭제하거나 값이 있는지 확인할 때 배열보다 빠르게 연산 가능 → Set은 해시테이블 자료구조를 가지고 있기 때문이다.

Set의 중요 메소드와 속성

• add() (값을 추가)
• delete() (값을 삭제)
• has() (값의 존재 여부)
• size (값의 개수 확인)

Set 생성

set은 new 키워드와 생성자를 이용하여 객체를 생성할 수 있다. 또한 배열을 인자로 넘기면, 배열에 담긴 값으로 set가 만들어진다.

const set = new Set(); // Set(0) {size: 0}

const numSet = new Set([0, 1, 2]); // Set(3) {0, 1, 2}

값 추가: add()

시간 복잡도 : O(1)

add() 메소드를 사용하여 값을 추가할 수 있다. 중복값은 추가되지 않는다.

set.add(1); // Set(1) {1}
set.add("B"); // Set(2) {1, 'B'}
set.add(false); // Set(3) {1, 'B', false}

값 삭제: delete()

시간 복잡도 : O(1)

특정 값을 삭제하고자 할 때는 delete() 메소드를 사용하면 된다. delete 메소드의 인자값으로 삭제하고자 하는 요소를 넣어주면 된다.

• 값이 있어서 성공적으로 삭제했다면, true를 반환
• 값이 없어서 삭제에 실패했다면, false를 반환

set.delete(1); // true
set.delete(2); // false

값 존재 여부 확인: has()

특정 값이 set에 존재하는지 has() 메소드로 확인할 수 있습니다.

if (set.has("B")) {
  console.log("Set에 B가 존재합니다."); // Set에 B가 존재합니다.
}

값 개수 확인: size

set의 size 속성(메소드 아님!)을 통해 값의 개수를 확인할 수 있습니다.

console.log(set.size); // 2

모든 값 제거: clear()

clear() 메소드를 통해서 set의 모든 값을 제거할 수 있습니다.

set.clear(); // Set(0) {size: 0}

Set 순회

Set의 원소들은 인덱스로 접근 불가하다. 만약 순회하고 싶다면, for … of 문을 통해 순회할 수 있다.

for (const name of nameSet) {
  console.log(name);
}

// 배열처럼 forEach도 가능
nameSet.forEach((name) => console.log(name));

배열 ↔ Set 변환

배열 → Set

Set을 생성할 때 배열을 인자로 주면 된다. 배열 안에 중복 요소가 있다면, 중복 요소를 제거해준다.

const arr = [0, 1, 1, 2, 2, 3, 3, 3];
const set = new Set(arr); // Set(3) {0, 1, 2, 3}

따라서, 배열에서 중복 값을 제거하고 싶을 때 사용하면 매우 유용하다.

const nums = [1, 2, 2, 3, 4];
const uniqueNums = [...new Set(numbers)]; // 중복 값 제거 뒤 다시 배열로
console.log(uniqueNums); // [1, 2, 3, 4]

Set → 배열

Set를 spread 연산자(…)를 사용하여 전개하면, 쉽게 배열로 바꿀 수 있다. Array.from() 메소드를 사용할 때는 Set를 인자로 넘겨주면 된다.

const array = [...set]; // [1, 2, 3]

const array = Array.from(set); // [1, 2, 3]

레퍼런스

• [javascipt] Set vs Array 시간복잡도 비교 (+ 해시테이블이란?)
• 자바스크립트 세트(Set) 완벽 가이드

React에서 ref는 어떤 형태의 값이든 저장할 수 있는 변수로 생각할 수 있다. React에서 useRef Hook을 가져와 컴포넌트에 ref를 추가할 수 있다.

import { useRef } from 'react';
function Component (){
  const ref = useRef(0); // 초기값을 인자로 전달

  return <></>
}

아래는 ref의 구조이다.

{
  current: 0  // <- 저장하고 싶은 값을 useRef를 통해 전달한다
}

ref는 읽고 수정할 수 있는 current 프로퍼티를 가진 일반 자바스크립트 객체이다. ref는 state와 달리 값이 변해도 렌더링을 트리거하지 않으며, 값을 변경하면, 바로 변경이 반영된다.

ref.current = 4;
console.log(ref.current); // 4

🤔 언제 사용해야할까?

1) 값을 저장 싶을 때 (리렌더링 없이)

*값을 저장할 변수가 필요한데, 컴포넌트가 이를 기억할 필요가 있을 때 *

컴포넌트 내부에 일반 변수를 선언해서 사용하면, 컴포넌트가 리렌더링된 후에, 그 값을 기억하지 못합니다. 따라서 이때 ref를 사용하는 것이 적절하다. 다만, 주의해야할 것은 ref의 값이 변할 때, 렌더링을 발생시키지 않는다는 점이다. (반면, state는 값이 변할 때마다, 리렌더링한다.)

!codesandbox[gs2l9n?view=editor+%2B+preview&module=%2Fsrc%2FApp.js]

위 예시에서, 컴포넌트는 countRef.current가 증가할 때마다 다시 렌더링 되지 않는다. 위에서 ref 값을 증가시키는 버튼을 누르면, ref.current 값은 변한다. 하지만, 리렌더링이 되지 않기 때문에, 화면에 출력되는 ref.current에는 변화가 없다. 실제 ref.current가 증가되었는지 궁금하다면, alert로 확인하기 버튼을 눌러서 확인할 수 있다. 그러면 ref.current가 버튼을 누른 횟수만큼 증가했다는 사실을 알 수 있다.

예시) 타이머 조작

import { useState } from "react";

export default function TimerChallenge({ title, targetTime }) {
  const [timerExpired, setTimerExpired] = useState(false);
  const [timerStarted, setTimerStarted] = useState(false);

  // 게임 시작 (타이머 작동 시작 및 게임 시작)
  const handleStart = () => {
    // 상태 값으로 끝난 것만 알 수 있다.
    setTimeout(() => {
      // target time 후에 타이머가 끝난걸 표시
      setTimerExpired(true);
    }, targetTime * 1000);

    // 시작했다는 것을 표시하기 위한 상태 값
    setTimerStarted(true);
  };

  // 사용자가 타이머를 멈췄을 때
  const handleStop = () => {
    // 타이머를 끝내야 한다. (타이머를 어떻게 접근? 🤔)
  };

  return (
    <section className="challenge">
      <h2>{title}</h2>
      <p className="challenge-time">{targetTime} 초</p>
      {timerExpired && <p className="challenge-time">타이머가 끝났어요 😢</p>}
      <p>
        <button onClick={handleStart}>
          {timerStarted ? "멈추기" : "시작하기"}
        </button>
      </p>
      <p className={timerStarted ? "active" : undefined}>
        {timerStarted ? "타이머 진행 중..." : "타이머 정지"}
      </p>
    </section>
  );
}

지정된 시간 만큼 지났을 때를 유추해서, 사용자가 정지 버튼을 누르는 게임이다. 사용자가 "정지"버튼을 눌렀을 때 시작된 타이머에 접근할 수 있어야 하는데, 어떻게 해야할까? 이때 ref를 사용하기 적절하다.

export default function TimerChallenge({ title, targetTime }) {
  const [timerExpired, setTimerExpired] = useState(false);
  const [timerStarted, setTimerStarted] = useState(false);

  const timer = useRef();

  // 게임 시작 (타이머 작동 시작 및 게임 시작)
  const handleStart = () => {
    // 상태 값으로 끝난 것만 알 수 있다.
    timer.current = setTimeout(() => {
      // target time 후에 타이머가 끝난걸 표시
      setTimerExpired(true);
    }, targetTime * 1000);

    // 시작했다는 것을 표시하기 위한 상태 값
    setTimerStarted(true);
  };

  // 사용자가 타이머를 멈췄을 때
  const handleStop = () => {
    // javascript에서 clearTimeout을 통해 타이머를 끝낼 수 있다. 하지만 인자로 ID가 필요하다
    // → 해당 값을 ref에 저장
    clearTimeout(timer.current);
  };

  // ... 생략 ...

관리되어야하는 값이 있는데, timerID와 같이 ui와 직접적인 연관이 없어서 렌더링이 필요하지 않은 경우 ref를 쓰는 것이 좋다.

2) DOM 요소에 접근하고 싶을 때

DOM 요소에 접근하여, DOM 요소 속성의 값(input의 value, 요소의 크기 등)을 읽어오거나, 포커싱, 스크롤링 등 브라우저 API 함수를 가져와 실행시키고 싶을 때

ref는 문자열, 객체, 심지어 함수 등 모든 것을 가리킬 수 있다. 만약에 ref의 값을 html 요소와 같은 DOM 노드를 가리키도록 넣어주면, DOM 조작에 활용할 수 있다.

input 입력에 대한 조작을 할 때, 일반적으로 useState를 활용해서 구현할 수 있다. 하지만, 이렇게 조작하면, 사용자가 input에 값을 입력할 때마다 리렌더링된다. 만약, 특정 이벤트(폼 제출, 버튼 클릭 등)**에만 값을 input에서 읽어오는 것으로 충분하다면 어떻게 하면 될까?

import { useRef, useState } from "react";

export default function Player() {
  // 초기화를 안하면, 첫 렌더링 시에는 playerRef.current는 undifined 
  const playerRef = useRef(); // 보통, DOM 요소를 저장할거면, null로 초기화
  const [playerName, setPlayerName] = useState();

  const handleClick = (event) => {
    // 이벤트 핸들러에서 ref에서 값을 가져올 수 있다.
    setPlayerName(playerRef.current.value);
  };

  return (
    <section id="player">
      <h2>안녕하세요, {playerName ?? "OOO"} 님!</h2>
      <p>
        <input type="text" ref={playerRef} />
        <button onClick={handleClick}>이름 저장</button>
      </p>
    </section>
  );
}

위 예제에서는 "이름 저장 버튼"을 눌러줄 때, input의 값을 읽어서 반영해줄 수 있다. 즉, 버튼을 클릭했을 때, input DOM 노드에 직접 접근하여 value 값을 가져온다. state와 함께 사용한 이유는, 단순히 화면에 보여주기 위함이다.

일반적으로, React가 렌더링 결과물에 맞춰 DOM을 직접 조작하도록 설계되어 있기 때문에, DOM을 직접 조작하는 일은 많이 없다. → 즉, 일반적인 case에서 DOM 조작은 react의 일!

따라서 DOM 노드를 수정하거나 제거하기보단, 아래 상황일 때 ref를 사용하게 될 것이다.

1) DOM 노드에 접근해 값을 읽고 싶을 때(주로 이벤트 핸들러에서) ** 2) 노드에 정의된 내장 브라우저 API**를 사용하고자 할 때

// 이벤트 핸들러에서 DOM 노드를 접근하기 위해 사용
function handleClick() {
  inputRef.current.focus();
}
// 예를 들어 이렇게 브라우저 API를 사용하거나,
myRef.current.scrollIntoView();

Ref로 DOM을 직접 조작해도 될까?

import { useRef, useState } from "react";

export default function Player() {
  const playerRef = useRef();
  const [playerName, setPlayerName] = useState();

  const handleClick = (event) => {
    // 이벤트 핸들러에서 ref에서 값을 가져올 수 있다.
    setPlayerName(playerRef.current.value);
    playerRef.current.value = "";
  };

  return (
    <section id="player">
      <h2>안녕하세요, {playerName ?? "OOO"} 님!</h2>
      <p>
        <input type="text" ref={playerRef} />
        <button onClick={handleClick}>이름 설정</button>
      </p>
    </section>
  );
}

위 코드를 보면, 브라우저에게 input의 값을 빈 문자열로 바꾸라고 명령하고 있다. 직접 조작하지 않고,React가 DOM과의 상호 작용과 관련된 역할을 일임한다는, 개념을 위반하고 있다.

그럼에도 불구하고 그저 input을 지우고 싶은 경우에는, input이 state와 연결되어 있지 않으니, 위처럼 그냥 코드를 작성해봐도 된다. (코드 양을 줄일 수 있다.) 다만, 페이지의 모든 값들을 ref로 읽고 조작하는데 사용하지 않도록 유의하여야 한다. 특히 노드를 삭제하는 행위는, 충돌을 일으킬 수 있으므로 유의해야한다. 공식문서에 있는 codesandbox를 통해 직접 확인해볼 수 있다. !codesandbox[w233t3?view=editor+%2B+preview&module=%2Fsrc%2FApp.js&hidenavigation=1]

결론 (Ref 사용법)

✅ 렌더링을 유발하지 않고 값을 저장해야 할 때 예: 타이머 ID, 이전 렌더에서 유지해야 하는 값 등

✅ DOM 요소를 직접 제어해야 할 때 예: input 값 가져오기, 포커스 주기, 스크롤 제어 등

⚠️ 주의사항 ❌ 값의 변경 시 리렌더링이 필요하면 사용하면 안 됨. ❌ DOM 노드 삭제 또는 직접 조작(값 변경 등)은 주의해야 함.

npm i styled-components

vscode에서 styled component css syntax를 적용하고, 자동완성 기능을 사용해보고 싶다면, vscode-styled-components 익스텐션을 설치한다.

기본 구조

import styled from "styled-components";

// const 컴포넌트이름 = styled.HTML태그종류 `css 코드 그대로`;
const Box = styled.div`
  background-color: royalblue;
  width: 100px;
  height: 100px;
  border-radius: 15px;
`;

function App() {
  return <Box />;
}

export default App;

확장

prop을 통한 확장

css 구조가 거의 동일한데, 몇가지 속성만 다른 경우 사용한다.

const Box = styled.div`
  background-color: ${(props) => props.bgColor};
  width: 100px;
  height: 100px;
  border-radius: 15px;
`;

function App() {
  return (
    <Container>
      <Box bgColor="royalblue" />
      <Box bgColor="deeppink" />
    </Container>
  );
}

위의 예시는 background-color 속성만 다른 경우 사용하는 방법이다.

상속을 통한 확장

class에서 확장하는 것과 같이 상속을 통해 확장할 수도 있다. 이때는 styled() 함수를 사용하여 나타낸다. 상속을 하고 추가하고 싶은 코드만 넣어주면 된다.

//... 일부 생략
const Circle = styled(Box)`
  border-radius: 50px;
`;

function App() {
  return (
    <Container>
      <Box bgColor="royalblue" />
      <Box bgColor="deeppink" />
      <Circle bgColor="gold" />
    </Container>
  );
}

태그 변경을 위한 확장

확장이 아닌, 특정 styled component의 style을 그대로 가져오려면 어떻게 해야할까? 즉, style 부분은 그대로 쓰고, 태그 부분을 바꾸고 싶다면, as 속성을 사용하면 된다.

const Circle = styled(Box)`
  border-radius: 50px;
`;

const Text = styled.span`
  color: purple;
  font-size: 2rem;
  font-weight: bold;
`;

function App() {
  return (
    <>
      <Container>
        <Box bgColor="royalblue" />
        <Box bgColor="deeppink" />
        <Circle bgColor="gold" />
      </Container>
      <Text>Hello</Text>
      <Text as="a" href="/"> Home</Text>
    </>
  );
}

Text 컴포넌트는 원래 span 태그이지만, as="a" 속성을 줌으로써 a 태그로 바꿔서 사용할 수 있다.

태그 속성 설정

HTML 기본 속성 Default로 주기

// 형식
const styled_컴포넌트이름 =
      styled.HTML태그이름.attrs({ HTML_속성_이름: HTML_속성값 })`css 코드`;

attrs() 함수를 통해 인자로 HTML_속성_이름 과 HTML_속성값을 짝지어 놓은 object를 넘겨주면, 해당 HTML_속성값이 default로 지정된 컴포넌트를 생성할 수 있다.

const Input = styled.input.attrs({ required: true })`
  display: block;
`;

function App() {
  return (
    <form>
      <Input placeholder="name" />
      <Input placeholder="phone number" />
      <Input placeholder="email" />
      <Input placeholder="birthday" />
    </form>
  );
}

모두 입력을 필수로 하는 input 태그를 생성할 수 있다.

애니메이션

// ⚠️ keyframes을 import 해주어야 한다.
import styled, { keyframes } from "styled-components";

// Animation의 정의
// animation 변수 keyframes helper function을 통해 만들기
const rotate = keyframes`
  from {
    transform: rotate(0deg);
  }
  to{
    transform:rotate(360deg);
  }
`;

// Animation이 추가된 styled component
const Elem = styled.div`
  background-color: royalblue;
  width: 100px;
  height: 100px;
  border-radius: 20px;
  animation: ${rotate} 3s linear infinite;
`;

function App() {
  return <Elem />;
}

Selector (선택자)

Pseudo Selector

일반 HTML 태그인 자식 element 선택하기

만약 아래 코드에서 스타일 컴포넌트가 아닌 자식 태그인 li를 선택해서 스타일을 주고 싶다면? 아래와 같이 li에 대한 css를 추가하면 된다.

const StyledUl = styled.ul`
  /*...css code*/
  li {
    color: whitesmoke;
  }
`;

function App() {
  return (
    <StyledUl>
      <li>this</li>
      <li>is</li>
      <li>the</li>
      <li>list</li>
    </StyledUl>
  );
}

위와 같이 부모인 sytled-component 자식 일반 엘리먼트들을 선택할 수 있다.

sytled-component인 자식 element 선택하기

자식도 컴포넌트가 일반 태그가 아니고, sytled-component인 경우도 선택자를 사용할 수 있다. 사용법은 아래와 같다.

// 커스텀 컴포넌트를 만들고
const List = styled.li`
  color: black;
`;

// 커스텀 컴포넌트를 선택자로 사용한다.
const StyledUl = styled.ul`
  /* ... css 코드 */
  ${List} {
    color: whitesmoke;
  }
`;

function App() {
  return (
    <StyledUl>
      <List as="span">this</List>
      <List>is</List>
      <List>the</List>
      <List>list</List>
    </StyledUl>
  );
}

state selector

&를 통해 자기자신에 대한 css를 추가적으로 정의할 수 있다.(:hover 과 같은 속성을 쉽게 정의해줄 수 있다.)

const List = styled.li`
  color: black;
  &:hover{
    color: white;
  }
`;

타입스크립트와의 사용법

Styled Components에도 타입을 지정해주어야 타입스크립트와 사용할 수 있다.

Type Definition 설치

Styled Component는 DefinitelyTyped에서 설치할 수 있다.

npm i --save-dev @types/styled-components

DefinitelyTyped 는 유명한 npm 라이브러리의 타입 definition을 담은 레퍼지토리이다. @types/의 파일 안에 정의되어 있다.

Interface를 통한 타입

필수가 아닌 스타일은 ? 를 통해 optional로 줄 수 있다.

interface ContainerProps {
    width: string;
      bgColor?: string;
}

const Container = styled.div<ContainerProps>`
    width: 200px;
`;

좋은 기회로 메타버스 콘테스트라는 대회에 참여하게 되었다. 감사하게도 기획서가 예선을 통과하게 되었고, 이제 본격적으로 개발에 들어가려고 한다. 우리 팀은 많은 동시 접속을 수용하고, 한글을 지원하며 다양한 기능을 지원하는 메타버스 플랫폼인 "ZEP"을 사용해 개발하기로 하였다.

아직 메타버스라는 개념이 익숙하지 않고, 개발 관련 내용도 그리 많지 않은 것 같다. ZEP에 들어가면, ZEP 개발 문서가 생각보다 정말 자세하게 한글로 작성되어 있다. 그리고 부족하지만 ZEP 개발을 시작하려는 누군가에게 도움이 되지 않을까 하여 개발 과정을 글로 정리해 보려 한다. 개발 환경 구축과 개발 과정 그리고 시행착오를 정리하여 담을 예정이다.

HELLO, ZEP!

🌐 ZEP 사이트 방문하기 ZEP은 네이버에서 개발한 메타버스 플랫폼으로 게더타운과 유사한 UI/UX를 제공한다. 주로 2D로 된 맵에서 미니 게임, 온라인 회의 등의 기능을 사용할 수 있다. 유저가 쉽게 이동하여 타인과 대화할 수 있는 가상공간을 제공한다. ZEP을 통해 실제 맵을 구현할 수도 있고 다양한 기본 가상 공간(사무실, 교실, 사교 모임 및 비즈니스에 맞춰 나온 공간)을 자유롭게 활용할 수 있다.

개발 환경 구축

ZEP은 ZEP script라고 Javascript 언어를 사용한다. Javascript로도 충분히 개발할 수 있지만, 이번 대회에서는 Typescript로 개발하는 것을 도전해보려고한다. Typescript를 통해 안정성있는 개발을 할 수 있을 것으로 기대된다. 그리고 ZEP 맵 공간을 개발하면서 Typescript를 연습할 수 있는 기회도 될 수 있을 것 같다.

ZEP script 설치

npx zep-script init {폴더 이름} --npm

위의 커맨드로 ZEP Script를 개발할 수 있는 환경을 구축할 수 있다. 설정한 폴더 이름으로 아래와 같은 폴더와 파일이 생기게 된다.

개발할 때 실질적으로 사용하는 폴더 및 파일은 위의 res 폴더와 main.ts 파일이다.

res 폴더

res 폴더는 ‘resources’의 약자로, 앱에 필요한 이미지나 html 파일 등을 넣을 경로이다.

main.ts

main.ts 파일은 실질적인 앱개발 코드를 적는 파일이다.

package.json

"scripts": {
    "build": "zep-script build",
    "archive": "zep-script archive",
    "deploy": "zep-script publish"
  },

앱 빌드

zep script는 javascript로 구동되기 때문에 typescript 코드를 컴파일해야 한다. 컴파일을 한 뒤 빌드해주는 커맨드는 아래와 같다.

npx zep-script build

그런데 package.json 폴더에 "build": "zep-script build" 라고 되어 있어서 아래 커맨드로 해도 괜찮은 것 같다. (혹시 잘못된 방법이라면, 댓글로 알려주세요!)

npm run build

빌드에 성공하면, dist 라는 폴더가 생기게 된다. dist 파일안에는 main.ts 파일이 javascript로 컴파일된 파일이 존재하게 된다.

앱 압축하기

만든 앱을 배포하기 위해서는 먼저 main.js, res안의 이미지, html 파일 등을 함께 압축한 .zip 파일을 만들어야 한다. 실제 배포될 파일은 바로 이 zip 파일이다. 명령어는 아래와 같다.

npx zep-script archive

마찬가지로 package.json 폴더에 "archive": "zep-script archive" 라 명시되어 있기 때문에, 아래 명령어로 실행해도 된다.

npm run build

앱 배포

사실 배포 가이드는 ZEP Script 가이드에 잘 나와있다. 웹페이지에 직접 파일을 올려 배포하는 방법은 아래 링크를 참조하면 좋을 것 같다. ↗️ ZEP Script 배포 가이드

CLI 배포

배포를 하기 전에 먼저 앱을 만들어야 한다. ZEP 로그인 > 나의 앱(Beta) > + 앱 업로드를 눌러 앱을 생성한다. 버튼을 눌렀을 때 아래와 같은 창이 뜨게 된다. 빈칸의 필수 항목을 입력해주면 된다.

이제 프로젝트 폴더에서 zep-script.json 파일을 수정해주어야 한다. 앱을 생성해준뒤 URL을 확인해보면 아래와 같이 apps/ 다음에 생긴 문자열이 바로 앱 아이디이다. Json 파일에 복사해서 쓰면 된다.

zep-script.json 파일 내용은 아래와 같다.

{
    "appId": "",
    "name": "Template",
    "description": "Template application",
    "type": "normal"
}

처음엔 appId 키 값이 빈 문자열일텐데, 여기에 앱 아이디 값을 붙여넣기 하면 된다. 그리고 앱 이름과 앱 설명에 대한 항목은 각각 name, description 값으로 주면 그 값으로 다시 설정된다. type도 설정해야하는데, type의 종류에 대해서는 다음 장에서 설명하겠다.

실제 배포를 위한 명령어는 아래와 같다.

npx zep-script publish

또는

npm run deploy

앱의 타입

ZEP의 앱에는 총 세가지의 타입이 존재한다. 노말 앱, 미니게임, 사이드바 앱이다.

노말 앱

노말 앱은 특정 맵에서만 작동하는 스크립트로, 해당 맵이 실행됨과 동시에 적용된다. 설정은 먼저 앱을 나의 앱에 등록한 다음, 적용하고 싶은 맵의 에디터에서 [맵 에디터] > [좌측 하단 맵 관리자 메뉴] > [맵 설정]으로 들어가 설정할 수 있다.

미니게임

미니게임은 어느 맵에서나 사용할 수 있는 설치형 앱이다. 사용자가 사이드 바의 미니게임 아이콘을 클릭한 다음에 미니게임을 클릭해서 사용할 수 있다. 한 사용자가 미니게임을 시작하면, 맵 전체에 있는 사용자에게 모두 게임이 시작된다. 게임을 시작하게 되면 시작한 자리에 게임 박스가 생기게 되는데, 실행한 사용자가 스페이스 바를 눌러 점프하게 되면, 게임 도중이라도 바로 종료할 수 있다.

사이드바 앱

사이드바 앱은 PC 좌측 사이드바에 아이콘으로 표시되는 앱이다. 사이드바 앱을 개발하고 업로드한 뒤, Owner 권한을 가진 맵의 플레이 화면에서 [사이드바] > [앱 스토어 아이콘] > [나의 앱] 리스트에서 추가해 사용할 수 있다. Owner가 한번 추가해놓으면, 그 스페이스에서는 입장한 모든 사람에게 사이드바 앱이 노출된다.

앱의 종류에 따른 배포 설정

앱의 종류는 배포시 zep-script.json 파일의 type 값으로 명시할 수 있으며 값의 종류에는 "normal", "minigame" 그리고 "sidebar"가 있다.

node.js와 vscode가 설치 되어 있다고 가정하고 시작한다. 새 프로젝트를 만들고 싶은 폴더를 vscode로 열고 터미널을 켜 아래 코드를 실행한다.

npm init -y

npm init 을 통해 새 프로젝트의 npm package를 초기화할 수 있다. -y 옵션은 생성할 때 질문을 묻는 경우가 있는 데 이에 대해 모두 yes로 대답하고 실행시킨다는 것이다. 그러면 아래와 같은 파일이 생성된다.

typescript 설치

아래 커맨드를 터미널에 실행시켜주면, typescript를 다운받을 수 있다.

npm i -D typescript

i 명령어는 install 과 같은 의미이고, -D 는 --save-dev의 의미와 같은 의미로 패키지가 devDependencies로 등록된다는 의미이다. 이것을 모두 package.json 파일에서 확인할 수 있다.

dependencies vs devDependencies

dependencies

배포용 라이브러리의 목록을 나타낸 곳이다. 일반적으로 그냥 npm install packagename 의 명령어를 통해 설치를 하면 배포용 라이브러리 목록에 뜨게 된다. 배포용 라이브러리는 npm run build로 빌드를 하면 최종 애플리케이션 코드 안에 포함된다.

// package.json
{
  "dependencies": {
    "packageName": "^1.0.0"
  }
}

devDependencies

개발용 라이브러리의 목록을 나타낸 곳이다. -D 는 --save-dev의 옵션으로 라이브러리를 설치한 경우 여기 목록에 나타난다. 배포용 라이브러리와는 달리 개발용 라이브러리는 빌드하고 배포할 때 애플리케이션 코드에서 빠지게 된다. 따라서 최종 빌드된 어플리케이션에도 라이브러리 기능이 적용되야 하는 경우에는 devDependencies로 설치하면 안된다.

// package.json
{
  "devDependencies": {
    "packageName": "^1.0.0"
  }
}

우리가 typescript를 devDependencies로 설치한 이유는 우리가 build할 때 typescript 자체를 쓸 것이 아니라 코드를 작성한 뒤 자바스크립트로 다시 바꿔 사용할 것이기 대문이다.

만약 배포용 혹은 개발용의 설정을 잘못하여 설치한 경우에는, 그 패키지 이름과 버전명이 나와있는 코드줄을 옮겨주기만 하면 된다. 명령어를 통해 다시 설치를 할 필요는 없다.

설치 완료 시 package.json 파일

소스파일 폴더 생성

소스파일을 저장할 src 폴더를 하나 생성해준다.

컴파일

우리가 타입스크립트를 사용하여 프로그래밍할 것이긴 하지만, 실제 브라우저에서는 타입스크립트를 알아듣지 못한다. 우리가 개발할 때만 타입스크립트를 사용하고 다 작성한 파일은 일반 자바스크립트로 다시 바꾸어서 사용한다. 이렇게 타입스크립트에서 자바스크립트 파일로 바꾸는 작업을 컴파일이라고 한다. 컴파일할 때 사용하는 명령어는 tsc 로 터미널에서 아래와 같이 쓰면 컴파일된다.

tsc filename.ts

위의 명령어를 실행시켜주면, filename.ts의 내용을 javascript로 변환한 filename.js 파일이 생성된다. 다만, 우리는 typescript를 전역으로 설치한 것이 아니기 때문에, tsc라는 명령어를 npm script로 만들어줘야 한다.

npm script 만들기

npm script에 커스텀 명령어를 추가해줌으로써, 우리만의 명령어를 만들수 있다. package.json 파일에 들어가 script옵션을 아래와 같이 수정해준다.

"scripts": {
    "build": "tsc"
},

이렇게 하면 build라는 명령어를 커스텀으로 만들고 실제 실행 명령어는 tsc로 설정할 수 있다. 이런 사용자지정 명령어를 실행하기 위해선 npm run 명령어 이름 을 터미널에 작성하면 된다. 위의 예시에서는 npm run build로 하면 된다.

이 밖에 컴파일된 파일의 저장위치나 변환된 자바스크립트의 버전 등 우리는 다양한 컴파일 규칙을 정해야한다. 이렇게 타입스크립트의 컴파일 방식과 규칙을 작성해줄 수 있는 파일이tsconfig.json 이다.

tscofing.json

파일 생성

touch tsconfig.json

CLI 환경에서 파일을 생성하는 명령어인 touch를 이용하여 tscofig.json 파일을 생성하였다. 꼭 이렇게 하지 않아도 vscode에서 파일 생성 버튼 이름을 눌러 tscofig.json의 이름으로 파일을 생성해줘도 상관없다.

파일 설정

tsconfig.json 파일이 있는 디렉터리가 TypeScript 프로젝트의 루트가 된다. 다시한번 파일의 역할을 설명하자면, tsconfig.json 파일은 프로젝트를 컴파일하는 데 필요한 루트 파일과 컴파일러 옵션을 지정하기 위한 파일이다. 파일 안의 내용은 object 형식으로 적어주면 된다. vscode를 사용하면 tsconfig.json 파일에서 사용할 수 있는 다양한 옵션을 자동완성으로 보여준다.

파일에서 사용가능한 옵션

각 옵션별 상세한 의미 (by 캡틴판교)

{
  "include": ["src"],
  "compilerOptions": {
    "outDir": "build",
    "target": "ES6",
    "lib": ["ES6", "DOM"]
  }
}

기본 옵션은 위와 같다. 컴파일할 파일의 위치와 컴파일된 파일이 저장될 폴더, 어떤 버전의 자바스크립트로 변환할 것인지, 컴파일할 때 어떤 라이브러리를 포함시킬 것인지에 대한 옵션을 설정한 것이다. 이 밖에도 자주 쓰는 compilerOptions 의 옵션에는 allowjs, checkJS, noImplicitAny 등이 있다.

+) 오류: No inputs were found in config file

stackoverflow 질문글 참고 include로 지정해준 디렉토리 안에 타입스크립트가 없어서 생기는 오류이다. 해당 디렉토리에 컴파일하고 싶은 타입스크립트 파일을 넣어주자.