Junvely 개발일기

Typescript 앱 생성하기(초기 셋팅 방법)

junvely — Thu, 28 Nov 2024 16:40:31 +0900

JS 프로젝트를 TS 프로젝트로 마이그레이션 하기 or TS 템플릿으로 생성하기

-> 마이그레이션 시 보통 파일을 하나씩 변경한다.

1. 직접 react-create-app 마이그레이션 하기

1) 리액트 앱 생성 및 타입 선언 패키지 install

   npx create-react-app .
   npm i @types/node @types/react @types/react-dom @types/jest`

2) tsconfig.json 설정하기

{
  "compilerOptions": {
    "target": "ES5",
    "module": "CommonJS",
    "strict": true,
    "allowJs": true,
    "esModuleInterop": true, // 외부 패키지 등에서나 export default가 없어도 기본옵션으로 추가하기
    "jsx": "react-jsx" // ts는 기본적으로 jsx해석못하기 때문에 추가
  },
  "include": ["src"]
}

3) 모든 js파일을 jsx 컴포넌트로 변경

-> 타입스크립트의 컴파일러(tsc)가 파일 확장자와 구성 옵션을 통해 코드의 의도를 명확히 구분하기 때문

-> .js와 .jsx는 순수 JavaScript 코드로 간주되며, 기본적으로 타입 검사를 최소화하거나 생략한다.

따라서, .js 파일에서 JSX를 사용하면 타입스크립트는 이를 별도의 설정 없이는 처리하려고 시도하지 않는다.

4) 개별 파일들 tsx로 하나씩 변경 후 에러를 옵션 등으로 해결하기

//index.tsx 에러 
const root = ReactDOM.createRoot(
  document.getElementById("root") as HTMLElement // 단언 추가
);
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

2. 한 번에 ts 프로젝트 생성하는 방법(ts 템플릿)

 npx create-react-app my-app --template typescript
 // 또는 현재 폴더에서 생성하기
 npx create-react-app . --template typescript

<참고>

[React] create-react-app & Typescript 초기 세팅 완벽 정리

최근에 타입스크립트를 배우고 타입스크립트로 create-react-app을 설정하는데 시간이 많이 걸렸다..그리고 새로 프로젝트를 시작할 때 초기세팅을 완벽하게 하자! 라고 생각을 해서 협업을 할 때

velog.io

[TypeScript] tsconfig.json 설정 옵션 알아보기

junvely — Tue, 22 Oct 2024 18:44:25 +0900

1. tsconfig.json

tsconfig.json에서는 이렇게 컴파일러 옵션을 설정할 수 있는데, 컴파일 시 얼마나 엄격하게 타입 오류를 검사할지, 자바스크립트 버전을 어떻게 할지 프로젝트에 따라, 개발자의 입맛에 맞춰 설정할 수 있다. tsc --init으로 초기화 하면 tsconfig.json 파일이 기본옵션으로 생성된다.(직접 생성해도 된다)

1) "include" : 컴파일할 파일이 많을 경우, 일일히 컴파일 하지 않고 특정 위치 기준으로 아래의 모든 파일을 컴파일하도록 설정할 수 있다.

{
  "include": ["src"]
}

2) "compilerOptions" : "target", "module", "outDir", "strict", "mpduleDetection" 등

  {
  "compilerOptions": {
    "target": "ES5", //컴파일 될 자바스크립트 버전 설정 가능
    "module": "CommonJS", // 자바스크립트 모듈 시스템 버전을 설정 가능
    "outDir" : "dist", // 컴파일 될 js파일들을 어디에 위치할지 설정 가능
    "strict": true, // "엄격한 타입 검사"하도록 지정(매개변수에 타입 지정안하면 오류)
    "strictNullChecks": false, // null타입을 엄격하게 검사할지 여부(다른 타입에 null 넣을 수 있음)
    				// "strict"의 하위 옵션이기 때문에 해당 옵션이 꺼져있으면 같이 꺼진다.
     "moduleDetection": "force", // 타입스크립트의 전역 모듈들을 개별 모듈로 자동 변환
     "skipLibCheck": true, // @types 버전이 20버전 이상으로 업데이트 되면서 이후 모든 tsconfig.json에옵션 추가
     			위 옵션은 타입 정의 파일(.d.ts 확장자를 갖는 파일)의 타입 검사를 생략하는 옵션.
				보통 타입 정의 파일은 라이브러리에서 사용하는데 가끔 라이브러리의 타입 정의 파일에서 타입 오류가 발생하는 일이 발생할 수 있다.
				따라서 해당 옵션을 true로 설정하셔서 불 필요한 타입 정의 파일의 타입 검사를 생략하도록 설정.
  	 
  },
  "include": ["src"]
}

❗ "undici-types" 에러 날 경우 : "skipLibCheck": true 옵션은 타입 정의 파일(.d.ts 확장자를 갖는 파일)의 타입 검사를 생략하는 옵션. 보통 타입 정의 파일은 라이브러리에서 사용하는데 가끔 라이브러리의 타입 정의 파일에서 타입 오류가 발생하는 일이 발생할 수 있다.따라서 해당 옵션을 true로 설정하셔서 불 필요한 타입 정의 파일의 타입 검사를 생략하도록 설정.

❗ "moduleDetection" : 자바스크립트에서는 하나의 파일을 독립적 모듈로 취급하지만, 타입스크립트에서는 모든 파일을 전역 모듈로 취급한다.

즉 각각 파일에 변수명이 같아도 자바스크립트는 독립된 모듈이라 전혀 상관없지만, 타입스크립트는 동일한 전역 스코프로 취급되어 에러가 발생한다. 이에 2가지 해결방법이 있는데,

1) 한 파일에 export 또는 import 등 모듈시스템을 1번 이상 강제로 사용 하여 독립된 모듈로 취급한다.

2) tsconfig.json에 "moduleDitection" : "force" 옵션을 추가한다. (에러 안사라지면 ctr+shift+p 로 restart 검색하여 ts 다시 검사) -> 이렇게 하면 컴파된 js파일에 자동으로 export 키워드가 추가시켜 개별 모듈로 변환 것을 확인할 수 있다.

<참고>

위 내용은 인프런 이정환 '한입 크기로 잘라먹는 타입스크립트' 강의를 공부하며 작성하였습니다.

[TypeScript] 타입 스크립트의 필요성과 동작 원리

junvely — Tue, 22 Oct 2024 16:11:06 +0900

1. 타입 스크립트가 등장하게 된 계기

자바스크립트는 본래 간단한 프로그래밍을 위해 만들어졌기 때문에 웹 브라우저에서만 작동하고, 유연하게 설계되었다는 장점이 있었다. 하지만 자바스크립트의 인기가 더욱 커지고 Node.js가 등장하게 되면서 웹 브라우저 외의 환경에서도 사용이 가능해졌고 활용도가 높아지면서 더 복잡한 프로그래밍에도 널리 사용이 가능해졌다.

이렇게 되면서 자바스크립트의 장점인 '유연함'과 자유로움은 곧 버그 발생 가능성이 높다는 문제점을 야기하게 되었고 더욱 안정적인 프로그래밍을 위해서 타입 스크립트가 등장하게 되었다. 이로써 타입 스크립트는 자바스크립트의 문법은 유지한 채, 타입과 같은 안정적인 문법이 추가된 자바스크립트의 확장된 언어라고 할 수 있다.

2. 자바스크립트의 한계점

1) 자바스크립트는 동적 타입 시스템이다. 곧 정적 타입 시스템(자바, c언어)과 달리 변수의 타입들을 런타임 중에 결정한다.(정적 타입 시스템처럼 우리가 직접 타입을 정의하지 않는다. ex.파이썬, 자바스크립트)

2) 변수의 타입이 고정적이지 않고 런타임 도중에 변경된다(유연함).

3) 타입으로 인한 오류 발생 시, 정적 타입 시스템같은 경우 실행 전에 이미 검사하여 즉시 실행이 안되지만 동적 타입 시스템인 자바스크립트는 즉시 실행이 멈추지 않고 나중에 갑자기 에러가 나는 등의 문제가 발생한다. 즉 개발자에 의한 타입 실수를 잡아주지 못하여 나중에 더 큰 문제를 발생시킨다.

4) 하지만 정적 타입 시스템은 실행 전에 타입 검사를 하여 안정적이라는 장점과 동시에 모든 변수에 타입을 명시해야 하기때문에 타이핑 양이 엄청나다는 단점이 있다.

타입 스크립트는 독특한 타입 시스템(점진적 타입 시스템)을 가지고 있다 -> 정적 + 동적 타입 시스템의 장점을 모두 가지고 있어 안정적이면서도 유연하다. 정적 타입 시스템처럼 타입 오류가 나면 알려주기 때문에 안전하면서, 일일히 모든 변수에 타입을 지정하지 않아도 타입이 명시되어 있지 않은 변수는 '점진적 타입 추론'을 통해 타입을 자동으로 인지한다.

3. 타입스크립트는 어떻게 동작할까?

1) 대다수의 프로그래밍 언어는 고급언어에 가깝다. 따라서 사람이 이해하기 쉬운 프로그래밍 언어를 기계어로 변환하는 '컴파일(Compile)을 통해 컴퓨터가 이해할 수 있는 언어로 변환하는 작업을 거쳐야 한다. 컴파일된 언어 = 바이트 코드

컴파일 과정은 프로그래밍 언어를 -> AST(추상 문법 트리)구조로 만들고 쪼개어 -> 바이트 코드로 변환한다.

2) 하지만 타입 스크립트의 경우 AST로 변환하고, AST를 보고 타입 검사를 먼저 실행 하여 문제 발생시 컴파일을 중단하고, 타입 검사 성공 시에는 바이트 코드가 아닌, 자바스크립트 코드로 변환한다. 그리고 컴파일이 종료된다.

이렇게 실행 전 타입 검사를 거쳐 컴파일된 자바스크립트 코드는 타입 검사를 통과한 비교적 안전한 자바스크립트 코드인 것이다. (타입 관련 코드들은 컴파일 시 모두 사라진다)

이렇게 컴파일된 자바스크립트 코드를 웹 브라우저나 Node.js환경에서 실행하면, 다시 한번 컴파일 과정을 거쳐 바이트 코드로 변환된다.

+ 컴파일과 인터프리터

브라우저에서 실행되던 자바스크립트는 전통적으로 컴파일이 필요없는 대표적인 인터프리터(interpreter) 언어였는데요. 브라우저나 Node.js는 우리가 작성한 자바스크립트 코드를 있는 그대로 이해하고 바로 실행할 수 있기 때문입니다.
컴파일(compile)은 소스 코드를 특정 플렛폼에서 실행 가능한 형태로 변환하는 과정을 의미하는데요. 기존에는 C++나 Java와 같이 자체 타입 시스템을 가진 프로그래밍 언어에서 주로 다뤄지던 개념이었으나, 타입스크립트의 등장 이후로는 자바스크립트에서도 컴파일이라는 용어를 심심치 않게 들을 수 있게 되었습니다.
자바스크립트 대신에 타입스크립트로 코드를 작성하는 것이 보편화됨에 따라 이제 많은 자바스크립트 프로젝트에서 컴파일 과정이 필요하게 되었습니다. 브라우저는 적어도 아직까지는 타입스크립트 코드를 있는 처리할 수가 없기 때문인데요. 따라서 개발 단계에서는 타입스크립트로 코드를 작성하지만, 배포할 때는 반드시 코드를 자바스크립트로 변환해줘야 하죠.

타입스크립트 컴파일러 사용법 (tsc 커맨드)

Engineering Blog by Dale Seo

www.daleseo.com

3. Node.js환경에서 typescript 실행 해보기

1. npm init 하여 패키지 환경 셋팅

node에서 사용하는 문법의 타입들을 설치

typescript 컴파일러 전역으로 설치

npm init
npm i @types/node
npm install typescript -g

4. 설치가 잘 됐는지 tsc(타입컴파일러) 버전 확인

$ tsc -v

5. index.ts 작성 후 tsc로 컴파일 해보기

//index.ts파일 작성
console.log("hello typescript");
const a: number = 1;

// 컴파일 하기 -> 컴파일된 자바스크립트 파일 생성됨
tsc src/index.ts

6. 컴파일된 자바스크립트 파일 생성됨 확인, index.js에서는 타입이 모두 사라짐 확인

- node에서 컴파일된 자바스크립트 코드 정상 실행됨 확인

node src/index.js

하지만 일일히 개발중에 tsc로 매번 컴파일, node로 확인할 수 없으니 ts-node 설치(ts를 즉시 실행까지 한번에 가능한 패키지다)

npm install ts-node -g
ts-node src/index.ts //실행 했더니 에러 발생

❗ts-node실행 시 에러 발생 : Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.

ES모듈을 사용하려면 package.json에 "type": "module"을 추가 했더니 .ts 파일을 실행 못한다는 또 다른 에러 발생.. 다시 제거하였다.

현재 자바스크립트 생태계에서는 여러 종류의 모듈 시스템이 공존하고 있다. Node.js와 ts-node에서는 CommonJS모듈을 사용하는 것과 같이 컴파일 시 module 종류를 지정하여 맞춰주어야 하는 문제 같다.

-> 결론 : Node.js가 CommonJS을 지원하기 때문에 ts-node를 사용할 때에 tsconfig.json 파일에 컴파일러옵션에 "module": "CommonJS"를 사용해야 한다. tsconfig.json 파일 생성 후, 컴파일러 옵션에서 "module" : "CommonJS" 를 설정해주니 정상 작동

// tsconfig.json 파일 생성
{
  "compilerOptions": {
    "preserveValueImports": false,
    "module": "CommonJS"
  }
}

❗ 하지만 컴파일된 코드를 Node.js의 구식 버전과 같이 CommonJS를 모듈 시스템으로 사용하는 실행 환경에서 돌릴 게 아니라면, 표준으로 자라잡고 있는 ES 모듈의 문법을 사용해서 컴파일해야 할 것이다. 이럴 경우 "module" 옵션을 "es6"으로 지정해주면 된다.

{
  "compilerOptions": {
    "preserveValueImports": false,
    "module": "es6"
  }
}

ts-node 정상 작동 확인!

하지만 이렇게 잘 되다가도 또 .ts에러가 나는 경우가 발생했다.... ts-node는 Node 20 버전 이상에서는 더 이상 동작하지 않는다고 한다. 따라서 ts-node 대신 tsx를 사용을 권장한다. tsx는 단 한번의 명령어로 타입스크립트 코드를 실행시켜주는 도구다.

npm i -g tsx
tsx src/index.ts

-> 사실 tsc로 컴파일을 실행할 때 아래와 같이 module 옵션을 지정해 줄 수 있는데, 매번 일일히 tsc로 모듈 지정하여 실행할 수는 없고 옵션들이 많아질 수록 작성이 길어지게 되니 tsconfig 파일에서 여러가지 옵션들을 설정해 놓면 편리하다.

$ npx tsc --module es6 index.ts

다음 글에서는 tsconfig.json 옵션에 대해 간단히 알아보도록 하자.

tsconfig.json 설정 옵션 알아보기

1. tsconfig.jsontsconfig.json에서는 이렇게 컴파일러 옵션을 설정할 수 있는데, 컴파일 시 얼마나 엄격하게 타입 오류를 검사할지, 자바스크립트 버전을 어떻게 할지 프로젝트에 따라, 개발자의 입맛

junvelee.tistory.com

<참고>

위 내용은 인프런 이정환 '한입 크기로 잘라먹는 타입스크립트' 강의를 공부하며 작성하였습니다.

[Next.js] App 디렉토리에서 route handlers로 API 구현하기 - Vercel Postgres + Prisma 풀스택 구현

junvely — Wed, 20 Mar 2024 01:46:28 +0900

[Next.js] App 디렉토리에서 route handlers로 API 구현하기

- Vercel Postgres + Prisma 풀스택 구현

1. Vercel Postgres 데이터베이스 설정

1. postgres와 vercel 설치

npm install @vercel/postgres
npm install -g vercel@latest

2. vercel에 프로젝트 배포 후 strorage에서 DB 생성(가까운 나라로) -> 프로젝트 연결(Connect Project) 확인(프로젝트명 맞는지 꼭 확인)

3. vscode 터미널에서 vercel 연결

vercel link

5. DB의 .env.local에 있는 키들을 .env파일에 옮겨오는 작업 / 옮겨지지 않을 경우 수동으로 복사해서 붙여넣으면 된다.

vercel env pull .env

6. Next api 생성하여 postgres가 잘 연결됐는지 확인해 보기

나는 app 디렉토리로 구성하여 app/api/movie/route.ts 파일에 route handlers(공식문서 참조)로 api를 생성하였다.

page 디렉토리라면 pages/api/movie.ts 파일에 api routes(공식문서 참조)로 api를 생성하면 될 것이다.

import { sql } from '@vercel/postgres';
import { NextResponse } from 'next/server';
 
export async function GET(request: Request) {
  try {
    const result =
      await sql`CREATE TABLE Pets ( Name varchar(255), Owner varchar(255) );`;
    return NextResponse.json({ result }, { status: 200 });
  } catch (error) {
    return NextResponse.json({ error }, { status: 500 });
  }
}

api 주소에서 다음과 같이 나오는지 확인해 보자 -> ex) http://localhost:3000/api/movie

{
  "result": {
  "command": "CREATE",
  "fields": [],
  "rowAsArray": false,
  "rowCount": null,
  "rows": [],
  "viaNeonFetch": true
  }
};

7. 데이터베이스 샘플 테이블 추가해보기

import { sql } from '@vercel/postgres';
import { NextResponse } from 'next/server';
 
export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const petName = searchParams.get('petName');
  const ownerName = searchParams.get('ownerName');
 
  try {
    if (!petName || !ownerName) throw new Error('Pet and owner names required');
    await sql`INSERT INTO Pets (Name, Owner) VALUES (${petName}, ${ownerName});`;
  } catch (error) {
    return NextResponse.json({ error }, { status: 500 });
  }
 
  const pets = await sql`SELECT * FROM Pets;`;
  return NextResponse.json({ pets }, { status: 200 });
}

api 주소에서 다음과 같이 나오는지 확인해 보자 -> ex) http://localhost:3000/api/movie

{
  pets: {
    command: "SELECT",
    fields: [
      {
        columnID: 1,
        dataTypeID: 1043,
        dataTypeModifier: 259,
        dataTypeSize: -1,
        format: "text",
        name: "name",
        tableID: 12345,
      },
      {
        columnID: 2,
        dataTypeID: 1043,
        dataTypeModifier: 259,
        dataTypeSize: -1,
        format: "text",
        name: "owner",
        tableID: 12345,
      },
    ],
    rowCount: 1,
    rows: [
      {
        name: "Fluffy",
        owner: "John",
      },
    ],
    viaNeonFetch: true,
  },
};

위와 같이 나온다면 연결 성공!

2. Prisma 설정 및 데이터베이스 스키마 생성

1. Prisma 설치 및 초기화

npm install prisma --save-dev
npx prisma init

2. prisma/schema.prisma 파일에서 db의 env키가 맞는지 확인 및 샘플 스키마 생성

vscode에서 활성화 안된 것 같이 코드에 불이 안들어와도 당황하지 말기....작동은 되고 있다..

// schema.prisma

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("POSTGRES_PRISMA_URL") // uses connection pooling
  directUrl = env("POSTGRES_URL_NON_POOLING") // uses a direct connection
}

model Post {
  id        String     @default(cuid()) @id
  title     String
  content   String?
  published Boolean @default(false)
  author    User?   @relation(fields: [authorId], references: [id])
  authorId  String?
}

model User {
  id            String       @default(cuid()) @id
  name          String?
  email         String?   @unique
  createdAt     DateTime  @default(now()) @map(name: "created_at")
  updatedAt     DateTime  @updatedAt @map(name: "updated_at")
  posts         Post[]
  @@map(name: "users")
}

3. Prisma 스키마를 기반으로 vercel 데이터베이스에 테이블 생성

npx prisma db push Prisma

실행하면 다음과 같은 질문을 한다. 이미 앞에 테스트 했던 데이터베이스 테이블이 존재하여 삭제를 진행해도 되냐는 말이었다. y를 입력한다.

완료가 되면 vercel의 storage의 data탭에 들어가 보면 prisma에서 생성한 스키마로 데이터 Post와 User 테이블이 추가된 것을 확인할 수 있다.

+ Prisma Studio를 사용하여 초기 데이터를 추가할 수 있다...!

npx prisma studio

3. Prisma 클라이언트 설치 및 생성

1. Prisma를 사용하여 Next.js에서 데이터베이스에 액세스하려면 Prisma Client를 설치해야 한다.

npm install @prisma/client

+ 만약 Prisma 스키마 파일이 변경될 경우, 다음 명령어로 prisma를 재생성 해야 한다.

npx prisma generate

3. 루트 디렉토리에서 lib폴더 내부에 prisma.ts 파일을 생성한다. -> PrismaClient 인스턴스를 생성한다. -> lib/prisma.ts

import { PrismaClient } from '@prisma/client';

let prisma: PrismaClient;

if (process.env.NODE_ENV === 'production') {
  prisma = new PrismaClient();
} else {
  if (!global.prisma) {
    global.prisma = new PrismaClient();
  }
  prisma = global.prisma;
}

export default prisma;

이렇게 하면 DB에 연결 할 때 마다 Prisma Client에 연결하여 prisma 인스턴스를 사용할 수 있게 된다.

4. 이제 드디어 Prisma를 사용하여 간단하게 데이터베이스에 연결해 보자!

import { NextResponse } from "next/server";
import prisma from "../../../lib/db";

export async function GET(request: Request) {
  try {
    const data = await prisma.user.findMany(); // user의 모든 결과 가져오기
    return Response.json({ data }, { status: 200 });
  } catch (e) {
    return NextResponse.json({ message: "fail" }, { status: 500 });
  }
}

감격스럽게도 내가 설정한 api주소에서(http://localhost:3000/api/movie )

방금 업데이트한(Prisma Studio에서 )따끈따끈한 user 데이터를 확인할 수 있었다.....❗

오늘은 여기까지......

다음 Prisma 공식문서에서 CRUD관련 메소드를 확인해 보자..!

Querying the database : typescript-postgresql

Write data to and query the database

www.prisma.io

<참고>

2. Prisma 연결

How to Build a Fullstack App with Next.js, Prisma, & PostgreSQL

Learn how to create and deploy a fullstack application with Next.js, Prisma, PostgreSQL, and Vercel.

vercel.com

[Next.js] CSR의 Link 태그의 원리, Link와 useRouter의 차이점

junvely — Mon, 18 Mar 2024 13:59:14 +0900

[Next.js] CSR의 Link 태그의 원리, Link와 useRouter의 차이점

1. CSR의 Link 태그의 원리

❓내가 궁금했던 부분 1 : Link태그를 사용하여 페이지 이동을 설정해놓을 경우 브라우저에서 소스 코드로 확인해 보면 <a>태그로 변환되어 있다. 이는 Link태그 내부에 <a>태그가 내장되어 있기 때문인데, 그렇다면 변환된 것은 <a>태그이므로 사용자가 클릭 했을 때에 새로고침이 일어나야 하는 것이 아닌가? 어떻게 부드러운 사용성을 유지할 수 있는가? 문득 궁금했다.

Next.js의 Link 컴포넌트를 사용하면 서버에서 받은 HTML에서는 <a> 태그로 변환되어 있으므로 기본적으로는 클릭 시 새로고침이 발생합니다.그러나 사용자의 브라우저가 JavaScript를 실행할 수 있고, JavaScript가 활성화되어 있는 경우에는 다음과 같은 과정으로 부드러운 화면 전환을 경험하게 됩니다:

1. 사용자가 Link 컴포넌트를 클릭합니다.
2. 브라우저는 JavaScript를 실행하고, 클라이언트 측 라우팅 메커니즘이 활성화됩니다.
3. 클라이언트 측 라우팅은 새로운 페이지의 필요한 컴포넌트 및 데이터를 로드합니다.
4. 화면이 부드럽게 전환되면서 새로운 페이지가 렌더링됩니다. 이 과정에서는 전체 페이지를 새로 렌더링하는 것이 아니라 필요한 부분만 업데이트됩니다.
5. 사용자는 새로운 페이지로 이동한 것처럼 보이지만, 실제로는 전체 페이지의 새로고침 없이 부드럽게 화면이 전환됩니다.

이러한 과정을 통해 사용자는 페이지 전환 시에 부드러운 경험을 할 수 있습니다. 이는 클라이언트 측 라우팅을 활용하여 페이지 간 전환을 빠르고 부드럽게 만드는 원리입니다.

내가 이해하기로는, Next.js와 같은 서버 사이드 렌더링에서는 서버로부터 렌더링된 HTML 문서를 받게 된다. 서버에서 받는 HTML에서는 Link가 a태그로 변화되어 클릭시 새로고침이 일어나야 하지만, 실제로 사용자가 클릭할 때 js가 켜져있다면 새로고침을 하지 않고 페이지는 유지하면서 내부 컴포넌트를 교체해주는 식으로 화면을 부드럽게 전환되는 것처럼 보이게 하는 것 같다. 또 js가 일어나지 않는 상황에서도 페이지는 이동되어야 하기 때문에 그런 경우에는 a태그를 통해 페이지를 새로고침 하는 것으로 보인다.

❓내가 궁금했던 부분 2 : Next.js 13 버전 부터는 서버 컴포넌트와 클라이언트 컴포넌트를 선택적으로 사용 가능하고, 클라이언트 컴포넌트에 한해서만 hydration이 일어나 CSR을 하는 것으로 알고 있다. 클라이언트 컴포넌트로 사용하기 위해서는 "use client"를 반드시 선언해 주어야 한다고 알고있다. 하지만 Link태그 같은 경우 "use client"를 사용하지 않아도 에러가 발생하지 않는다. 클라이언트 컴포넌트로 선언도 하지 않았는데 어떻게 자동적으로 Link를 사용하면 CSR 방식으로 페이지 이동이 가능한 것일까?

컴포넌트 모듈에 'use client' 지시어가 포함된 경우 해당 컴포넌트의 사용은 클라이언트 컴포넌트임이 보장됩니다. 하지만 컴포넌트에 'use client' 지시어가 없더라도 클라이언트에서 평가될 수 있습니다.

정적 생성을 사용하는 페이지의 경우 뷰포트의 모든 <Link /> 는 기본적으로 해당 데이터를 포함하여 미리 가져오기됩니다 (초기 또는 스크롤을 통해). 서버 렌더링 경로에 대한 해당 데이터는 < Link />를 클릭할 때만 가져옵니다

- 공식문서 참조 : https://ko.react.dev/reference/react/use-client

+ Link 컴포넌트는 Server Side Rendering + Client Side Routing이다. Next.js에서 제공하는 클라이언트 사이드 라우팅을 구현하는데 사용되며, 클라이언트 측 라우팅을 위한 컴포넌트이기 때문에, "use client"를 명시적으로 선언하지 않아도 클라이언트에서도 렌더링 된다. Next.js의 Link 컴포넌트가 기본적으로 클라이언트 측 라우팅을 지원하기 때문에 클라이언트 측에서만 동작하도록 설계되어 있기 때문이다.

1. Link 컴포넌트의 자동 클라이언트 측 렌더링: Next.js의 Link 컴포넌트는 자체적으로 클라이언트 측 렌더링을 수행하기 때문에 "use client"를 명시적으로 선언하지 않아도 클라이언트 측에서 렌더링됩니다. 이것은 Link 컴포넌트가 클라이언트 측 라우팅을 지원하기 위해 설계되었기 때문입니다.

2. JavaScript 번들의 서버 전달: 클라이언트 측 라우팅을 사용하는 경우에도, 서버에서 해당 페이지에 필요한 JavaScript 번들이 클라이언트로 전달됩니다. 이것은 클라이언트 측 라우팅을 위한 JavaScript 코드가 클라이언트로 전달되어야 하기 때문입니다.

3. Hydration 작업: Link 컴포넌트를 클릭하면 해당 페이지에 필요한 JavaScript 번들이 클라이언트로부터 다운로드되고 실행되며, 이를 통해 클라이언트 측 라우팅과 Hydration 작업이 수행됩니다. Hydration 작업은 클라이언트에서 미리 렌더링된 HTML과 일치하도록 페이지를 업데이트하는 과정을 의미합니다.

2. 'use Client' 동작 원리

1. React 서버 컴포넌트를 사용하는 앱의 경우, 기본적으로 앱은 서버에서 렌더링 됩니다. 'use client'는 모듈 종속성 트리에 서버-클라이언트 경계를 도입하여 효과적으로 클라이언트 모듈의 하위 트리를 만듭니다.

2. 'use client'는 React 서버 컴포넌트 앱의 모듈 종속성 트리를 분할하여 InspirationGenerator.js와 모든 종속성을 클라이언트-렌더링으로 표시합니다.

3. 렌더링하는 동안 프레임워크는 루트 컴포넌트를 서버-렌더링하고 렌더 트리를 통해 계속 진행하여 클라이언트에서 가져온 코드를 평가하지 않습니다. 그런 다음 서버에서 렌더링한 렌더 트리 부분을 클라이언트로 보냅니다. 클라이언트 코드를 다운로드한 클라이언트는 트리의 나머지 부분 렌더링을 완료합니다.

공식 문서 : 트리를 통해 잘 확인할 수 있으니 한 번 읽어보자.

3. Link와 useRouter의 차이점

가장 큰 차이점은 검색엔진(SEO)인것 같다.

Link

<a>태그로 변환되기 때문에 검색엔진이 링크를 인식할 수 있으므로 SEO를 보장하면서도 사용자 경험을 개선할 수 있다. -> 검색엔진이 indexing처리를 할 때 href속성을 읽어 indexing처리를 하는데 href가 없으면 검색엔진이 추적을 할 수 없다. href props는 Link태그를 사용할 때 필수로 사용해야하기 때문에 SEO에 유리하다.

useRouter

useRouter는 next.js에서 "함수형식"으로 routing을 해주는 Next.js가 제공하는 라이브러리이다. 크롤러가 링크를 감지하지 못해 SEO가 좋지 않을 수 있다. 페이지를 이동 할 때에 단순히 즉시 페이지를 이동하는 것이 아니라 어떤 비즈니스 로직 등을 수행한 후, 결과 처리로 페이지를 이동 하는 등 함수 형식의 기능을 수행할 때 사용한다. 외부 URL을 사용할 경우 window.location 혹은 a 태그를 사용해야 한다.

+ Next.js가 13버전이 release하면서 app routing기능을 추구하고있다. app routing을 사용한다면 useRouter는 next/router가 아닌 next/navigation에서 import하여 사용하여야 한다.

결론

Next.js의 Link 컴포넌트는 자체적으로 클라이언트 측 렌더링을 수행하기 때문에 "use client"를 명시적으로 선언하지 않아도 클라이언트 측에서 렌더링된다. 이것은 Link 컴포넌트가 클라이언트 측 라우팅을 지원하기 위해 설계되었기 때문이다. 클라이언트 사이드 라우팅과 클라이언트 사이드 렌더링, 클라이언트 컴포넌트와의 관계성이 모두 같아야 한다고 생각해서 계속 고민했던 것 같다. '서버 사이드 렌더링이면서, 클라이언트 사이드 라우팅을 사용하는 Next.js는 서버 컴포넌트에서도 클라이언트 사이드 렌더링이 가능하다'가 결론이다. 굳이 클라이언트 컴포넌트가 아니어도 가능하다 = 'use client'를 사용할 필요가 없다는 것이다.

또 React의 Link 태그와 Next.js의 Link 태그가 다른 점은 React는 클라이언트 사이드 렌더링, 클라이언트 컴포넌트 이기 때문에 서버사이드 렌더링을 하기 위해선 별도 구현이 필요하다는 점, Next.js에서는 prefetch와 같이 React의 기능을 확장하고 더 많은 기능을 제공한다는 점이다.

되도록이면 SEO를 위해 Link태그를 사용하는 것을 권장한다. 하지만 페이지를 즉시 이동하는 것이 아니라 어떤 로직을 수행 후에 이동해야 한다면 useRouter를 사용하면 될 것 같다.

[Next.js] Data fetching하기, Loading 및 Error Handling

junvely — Sun, 17 Mar 2024 18:52:32 +0900

Next.js 13이후 Data를 fetching하는 방법

1. 기존 React에서 컴포넌트에서 Data를 fetching하는 방법(클라이언트 컴포넌트 형식)

"use client";
import { useEffect, useState } from "react";

// export const metadata = {
//   title: "Home",
// }; // 클라이언트 컴포넌트에서는 meta data 사용불가

export default function Page() {
  const [movies, setMovies] = useState([]);
  const [isLoading, setisLoading] = useState(true);

  const getMovies = async () => {
    const res = await fetch(
      "https://nomad-movies.nomadcoders.workers.dev/movies"
    );
    const json = await res.json();
    setMovies(json);
    setisLoading(false);
  };

  useEffect(() => {
    getMovies();
  }, []);
  return (
    <>
      <div>{isLoading ? "Loading... " : JSON.stringify(movies)}</div> // 또는 usequery 등으로 로딩 상태 관리
     
    </>
  );
}

+ 네트워크 탭에서 우리가 요청한 api정보 등을 확인 가능하다. 보안에 취약하다.

2. 서버 컴포넌트에서 Data를 fetching하는 방법

클라이언트 컴포넌트와 달리 서버 컴포넌트를 사용하게 되면 useState나 useEffect, useQuery 등의 필요성이 사라지는 등 좀 더 편리해졌다.

컴포넌트 함수 외부에서도 함수 사용 가능하다.
useState, useEffetct를 사용하지 않아도 된다. -> 서버사이드 렌더링으로 데이터 fetching이 완료된 HTML페이지를 전달해 주기 때문 + 서버 컴포넌트에서는 클라이언트 사이드와 달리 사용자 상호 작용이 없으므로 상태 변화(라이프 사이클)를 관리할 필요가 없다. 서버 컴포넌트의 주된 목적은 초기 데이터 로딩 및 HTML 생성이므로, 상태를 관리할 필요성이 크게 줄어든다.
fetch 사용 시 프레임워크에서 자동으로 URL을 캐싱 해준다(useQuery 필요성 사라짐).
자동 캐싱 때문에 초기 data fetching 때에만 loading 상태가 필요하다. -> ❗하지만 서버에서 이루어지기 때문에 fetching될 때 까지 사용자가 아예 페이지 자체를 사용자가 확인할 수 없다. 때문에 사용자에게 로딩상태를 알려줄 수 있는 조치가 필요하다(아래에서 정리)
캐싱된 데이터가 아닌 최신 데이터가 필요할 경우 revalidation을 공부해 보도록 하자

export const metadata = {
  title: "Home",
}; //서버 컴포넌트에서는 metadata 가능

const URL = "https://nomad-movies.nomadcoders.workers.dev/movies";

//1. 서버 컴포넌트 -> 외부에 함수 작성 가능
async function getMovies() {
  console.log("i'm fetching!"); // 서버 컴포넌트기 때문에 서버에서 로그 찍힘
  //2. 서버 컴포넌트 사용시, Next.js에서 fetch한 URL을 자동으로 캐싱해줌, useQuery 필요없음
  // 최신 데이터가 필요할 경우 revalidation에 대해 공부하기
  const res = await fetch(URL);
  const json = await res.json();
  return json;
}
export default async function HomePage() {
  //3. useState, useEffect 필요 없음
  //4. loading state도 필요 없음 -> 캐싱되기 때문,
  //❗but, 처음에는 api요청에 따른 로딩 발생 -> 서버에서 html를 받을 때까지 사용자는 페이지를 확인하지 못함(서버가 로딩중인 상태)
  // 사용자가 로딩중인걸 바로 확인해야 함
  const movies = await getMovies();
  return (
    <>
      <div>{JSON.stringify(movies)}</div>
    </>
  );
}

컴포넌트에 async를 붙이는 것은 NextJs가 해당 컴포넌트에서 await 해야 하기 때문이다.

+ 리액트 라이프사이클(Life cycle)과 훅(Hooks)의 목적 복습하기

라이프사이클과 훅의 목적은 주로 컴포넌트의 생명주기에 따른 동작을 관리하고, 상태(state)를 효율적으로 관리하여 UI를 최신 상태로 유지하는 데 있다.

라이프사이클:
라이프사이클은 컴포넌트가 생성되고 소멸되는 과정에서 발생하는 다양한 이벤트를 의미한다. 예를 들어, 컴포넌트가 처음 렌더링될 때, 업데이트될 때, 혹은 제거될 때 특정 작업을 수행하고 싶을 때 라이프사이클 메서드를 사용한다. 이를 통해 컴포넌트의 초기화, 데이터 로딩, 상태 갱신 등을 관리할 수 있다.

Hooks의 목적 :
훅은 함수형 컴포넌트에서 상태와 생명주기 기능을 사용할 수 있게 해주는 React의 기능이다. useState, useEffect, useContext 등의 훅을 사용하여 컴포넌트의 상태를 관리하고, 생명주기 이벤트에 대응하여 특정 작업을 수행할 수 있다. 훅을 사용함으로써 클래스형 컴포넌트에서 제공되는 기능과 유사한 기능을 함수형 컴포넌트에서도 사용할 수 있게 되었다.

- 상태 관리: 컴포넌트의 상태를 관리하여 UI를 최신 상태로 유지한다. useState 훅을 사용하여 컴포넌트의 상태를 선언하고, 상태가 변경될 때마다 UI를 업데이트할 수 있다.
- 생명주기 관리: 컴포넌트의 생명주기에 따른 동작을 관리한다. useEffect 훅을 사용하여 컴포넌트가 마운트되었을 때, 업데이트되었을 때, 혹은 언마운트되었을 때 특정 작업을 수행할 수 있다.
- 부수 효과 관리: 데이터 가져오기, 구독 설정, 타이머 설정 등의 부수 효과를 관리한다. useEffect 훅을 사용하여 컴포넌트의 부수 효과를 관리하고, 필요한 경우 정리(clean-up) 작업을 수행한다.
따라서 리액트에서 라이프사이클과 훅을 사용하여 상태를 관리하고, 컴포넌트의 생명주기를 관리하여 UI를 최신 상태로 유지하는 것이 주요 목적이다.

3. Loading Components

page폴더 안에 loading.tsx를 생성하면, 서버가 렌더링될 때 동안 해당 페이지 자리에 로딩 컴포넌트를 보여준다.

사용자가 페이지를 요청하면, 서버가 즉시 먼저 준비된 작은 HTML문서들(청크) Navigator, Loading페이지 등을 먼저 전달하고, 백엔드 통신이 마무리 되지 않이 기다려야 함을 알림 -> component는 await 중 -> 서버가 데이터 fetching이 완료가 되면 해당 컴포넌트를 전달한다. -> Loading컴포넌트를 해당 컴포넌트로 바꿔줌 -> 서버가 content를 streaming 하는 것.

-> ❗하지만 매번 이런 식으로 폴더에 Loading 컴포넌트를 만들기는 번거롭다. 다른 대안이 필요하다.

+ 컴포넌트에 async를 붙이는 것은 NextJs가 해당 컴포넌트에서 await 해야 하기 때문이다.

export default async function HomePage() {
  await new Promise((resolve) => setTimeout(resolve, 5000));
  const movies = await getMovies();
  return (
    <>
      <div>{JSON.stringify(movies)}</div>
    </>

구글 검색엔진은 로딩페이지를 인식할까?
로딩 페이지나 Suspense를 사용하는 경우 Google 봇은 로딩요소를 볼 수 없다. 앞서 본 것처럼 페이지는 기술적으로 로드되지 않았으며 데이터가 도착할 때만 '공식적으로' 로드되기 때문이다. Google 봇은 페이지가 로드될 때까지 기다린다. 브라우저는 대기가 완료될 때까지 페이지가 로드되었다고 '생각'하지 않는다.

4. Parallel Requests (Promise.all)

같은 컴포넌트에서 동시에 다수의 데이터 통신을 수행할 경우, async await을 사용하면 먼저 실행된 데이터 통신이 마무리 된 후에, 다음 데이터 통신이 실행됨 -> 데이터 통신이 많고 오래걸릴 수록 -> 모든 데이터 통신이 완료될 때 까지 시간이 굉장히 오래걸린다.

const movie = await getMovie(id); // 2개의 데이터 통신 할 경우
const videos = await getVideos(id); // 1번이 완료되어야 2번이 진행됨 -> 병렬적으로 실행 방법 Promise.all

먼저 실행한 데이터 통신 -> 5초 뒤 다음 데이터 통신이 완료됨

-> Promise.all을 사용하면 모든 데이터 통신을 병렬적으로 동시에 수행 가능하다.

  const [movie, videos] = await Promise.all([getMovie(id), getVideos(id)]);

-> ❗하지만 이렇게되면 두 데이터 통신이 전부 끝나야지만 데이터를 확인할 수 있다. 분리할 수 있는 다른 대안이 필요하다.

5. Suspense

1. 2가지 데이터를 병렬적으로 통신하기 위해 컴포넌트를 분리(각 컴포넌트는 async)

2. Suspense를 이용하여 fallback에 loading 상태동안 보여줄 요소를 전달

3. 데이터 통신을 마치면 해당 컴포넌트로 교체됨

export default async function MovieDetail({
  params: { id },
}: {
  params: { id: string };
}) {
  return (
    <div>
      <Suspense fallback={<h1>Loading movie info</h1>}>
        <MovieInfo id={id} />
      </Suspense>
      <Suspense fallback={<h1>Loading movie videos</h1>}>
        <MovieVideos id={id} />
      </Suspense>
    </div>
  );
}

-> ❗만약 데이터 통신에 실패하거나 에러가 발생한다면 어떻게 에러 처리를 해야 할까?

6. Error Handling

로딩 컴포넌트와 똑같이 해당 폴더 내부에 error.tsx를 작성하면, 에러 발생시 해당 페이지를 자동으로 보여주게 된다.

나머지 html요소는 영향이 없고, 웹 사이트가 멈추지 않고, 해당 페이지만 error페이지로 보여진다.

애플리케이션이 멈추지 않고 다른 작업을 동시에 할 수 있다는 것이다. 만약 로딩, 에러 상태가 발생했다고 해서 전체 애플리케이션이 멈추는 것처럼 보이는 것은 치명적이며 사용자에게 좋지 않다. 따라서 부분적으로 로딩, 에러 상태를 보여주는 것이 좋다.

+ 읽어보면 좋을 참고 자료 :

Suspense, Error Boundary로 비동기 로딩, 에러 로직 공통화하기(feat. Next.js, React-Query)

Suspense, Error Boundary를 사용하여 선언적으로 깔쌈하게 비동기 로딩, 에러 로직을 공통화합니다.

velog.io

7. Dynamic Metadata(동적 메타데이타)

각 페이지마다 메타데이타 내용을 변경하고 싶을 경우 다음과 같이 generateMetadata를 설정해 주면 된다.

컴포넌트에 전달된 id props을 활용해 영화정보를 가져와서 title 정보로 메타데이타를 변경시켜 준다.

metadata를 업데이트 하기 위해 getMovie API를 실행하는건 좋지 않다고 생각할 수 있지만, 이전 버전이 아닌 최신 버전은 하위 컴포넌트에서 호출한 getMovie를 캐싱하기 때문에 두번째 호출한 fetch에서는 캐싱된 데이터를 사용한다.

interface Params {
  params: { id: string };
}

// metadata를 업데이트 하기 위해 getMovie API를 실행하는건 좋지 않다고 생각할 수 있지만,
// 이전 버전이 아닌 최신 버전에서는 하위 컴포넌트에서 호출한 getMovie를 캐싱하기 때문에
// 두번째 호출한 fetch에서는 캐싱된 데이터를 사용한다.
export async function generateMetadata({ params: { id } }: Params) {
  //컴포넌트와 같이 props을 받을 수 있음(id)
  const movie = await getMovie(id);
  return {
    title: movie.title,
  };
}

export default async function MovieDetail({
  params: { id },
}: {
  params: { id: string };
}) {

8. prefetch props

movie 페이지는 영화정보가 굉장히 많아 데이터가 로드되는데 오래걸리기 때문에 사용자가 비디오 목록을 확인하는데 오래 걸린다. 이 Link 부분에 prefetch props를 추가해준다.

<Link prefetch href={`/movies/${id}`}>
        {title}
      </Link>

이렇게 하면 NextJS는 해당 페이지의 데이터를 미리 로드하여 사용자가 더 빠르게 데이터를 확인할 수 있게 된다.

Network탭을 열어놓고 스크롤을 내리면 사용자가 링크를 클릭하지 않아도 미리 자동적으로 해당 페이지의 데이터를 받아오고 있는것을 확인할 수 있다. 해당페이지에 들어가면 로딩스피너는 더이상 확인할 수 없고 미리 로드한 데이터를 더 빠르게 확인 할 수 있다.

모든 페이지를 prefetch하라는 것은 아니다! DB가 죽을 수도 있다.. 하지만 필요시 적절히 사용할 수 있는 멋진 기능인 것 같다.

[Next.js] Route groups, Meta Data, dynamic routes 간단 정리

junvely — Sat, 16 Mar 2024 19:34:16 +0900

1. Route groups

폴더이름에 ()괄호를 넣어주면 url은 변하지 않고 페이지를 묶어줄 수 있다.

routes를 그룹화하여 logical groups로 만들 수 있다. 이렇게 관련된 페이지들을 그룹화 하면 좀 더 직관적으로 파악이 가능하다.

2. Meta Data

- 메타 데이터는 병합된다(다른 page에서는 title, layout에는 description 사용할 경우 병합되어 나옴)

- page나 layout 에서만 메타데이터를 내보낼 수 있다.

- 컴포넌트에서는 메타데이터를 내보낼 수 없다.

- 메타 데이터는 서버 컴포넌트에서만 있을 수 있다.

- title 등에 template 옵션으로 공통으로 띄울 문자열 지정이 가능하다. default는 기본값.

- 공식문서에서 여러가지 옵션들 확인 가능하다.

Optimizing: Metadata | Next.js

Use the Metadata API to define metadata in any layout or page.

nextjs.org

3. dynamic routes

폴더명/[id] 폴더 생성/page.tsx 으로 동적 라우팅 가능 -> [ ] 대괄호 필수 (리액트 동적라우팅 /movie/:id와 같지만 hook이 필요 없다.)

/movies/어떤주소가 와도 해당 page 띄워줌

-> 페이지에서 받는 /movie/123424 id를 받아와 보자

props을 받아서 console.log 해주면 ❗브라우저 console에 찍히지 않고 서버에서 찍히는걸 확인할 수 있다.

서버에서 렌더링되기 때문이다. id는 내가 중괄호로 설정한 이름이다 [ id ] 다른이름도 가능.

searchParams 는 주소창에 /movie/123424?region=kr 이런식으로 오면 아래와 같이 확인 가능하다. 검색 페이지 구현시 유용하게 사용한다.

/movie/123424?region=kr&page=2 결과

아래와 같이 정보를 얻을 수 있다.

[Next.js] Next.js Routing과 Hydronation, 'use Client' 알아보기

junvely — Fri, 15 Mar 2024 23:18:30 +0900

[Next.js] Next.js Routing과 Hydronation, 'use Client' 알아보기

Next.js에 대해 공부해보면서 알게된 내용들을 간단히 정리해 보고자 한다.

먼저 React는 라이브러리이고, Next.js는 프레임워크이다. 학습하면서 차이가 있었던 것은 리액트는 라이브러리 이기 때문에 폴더 구조, 이름, 라우팅, CSS, 하나부터 열까지 모든 선택과 결정을 내가 해야 했었다. 어떻게 보면 하나 하나 전부 고민해야 하고 여러가지를 공부하고 선택해야 하는 번거로움이 있었지만 내가 원하는 대로, 필요할 때 원하는 패키지와 개발 방식으로 자유롭게 개발할 수 있다는 장점이 있었다. Next.js같은 경우는 프레임워크기 때문에 그들이 정해놓은 룰과 규칙이 있었고, 라우팅 방식이나 폴더구조, 파일이름, CSS까지 그 규칙을 준수해야지만 개발이 가능했다. 하지만 나보다 더 멋진 개발팀이 짜놓은 규칙과 틀 안에서 보다 편리해진 기능으로 개발한다는 것이 어떻게 보면 개인적으로 안심도 되고 리액트에 비해 편리해진 기능들도 많았다. Next.js 프레임워크는 현재 리액트 메타 프레임워크 1위로 급부상할만큼 많은 인기를 끌고 있지만 한편으로는 13,14 등 최신 버전이 아직 베타 수준이고 아직 불안정하다는 여론도 많은 것 같다.

Next.js 13,14 버전 이후의 app 디렉토리가 등장하면서 편리해진 기능들이 많은 것같다. 어떤 사이드 이펙트가 있을지는 아직 잘 모르겠지만.... 그래도 계속해서 새로운 시도를 해보고 시야를 넓히는건 개발에 큰 도움이 될테니 차근차근 배우면서 간단히 정리해 보고자 한다.

1. Next.js 설치(수동 설치)

1. create next-app을 사용하지 않고 간단히 프로젝트를 생성해 본다. react, react-dom, next를 최신버전으로 설치해 준다.

npm install react@latest react-dom@latest next@latest

2. package.json에 "dev" : "next dev" 추가

"scripts": {
    "dev": "next dev",
    ...

3. src폴더 생성/app폴더/ 내부에 page.tsx 생성(13버전 app 디렉토리)

4. npm run dev로 앱을 실행시키면, typescript를 따로 설치하지 않아도 앱 실행과 동시에 typescript 패키지와, 폴더 구조까지 생성해 준다.

npm run dev

2. Router

Next.js에서 라우팅은 파일시스템을 통해 폴더 구조대로 url이 생성된다.

13 이전 버전에서는 pages구조를 사용하여 index.tsx, home.tsx 등 파일명으로 라우팅이 됐었다. -> / 또는 /home 으로 생성됨

├── /pages
│   ├── api
│   │     └── hello.ts
│   ├── _app_.tsx
│   ├── _document.tsx
│   ├── index.tsx  ----> /
│   └── page1.tsx  ----> /age1

13버전의 app 디렉토리 구조를 사용할 때는 aap/폴더명/page.tsx 방식으로 라우팅 한다. -> /폴더명 으로 생성됨

├── /app
│   ├── api(API Routes 지원 여부 불확실)
│   ├── page1 ----> /page1
│   │  ├──── page2  ----> /page1/page2
│   │  │    └── page.tsx
│   │  ├─── page.tsx //page명은 반드시 page.tsx 필수
│   │  ├─── layout.tsx
│   ├── layout.tsx
│   └── page.tsx

이때 폴더명으로 라우팅이 되며, 폴더 내부 페이지명은 반드시 page.tsx로 설정해 주어야 라우팅이 가능하다.

참고로 app 디렉토리로 구성할 경우에도, 모든 컴포넌트들은 서버 컴포넌트로 렌더링된다(RSC:React Server Component)

3. CSR vs SSR

먼저 SSR과 CSR에 대한 이해가 부족하다면 다음 포스팅을 통해 공부하고 오도록 하자.

CSR(Client Side Rendering)과 SSR(Server Side Rendering)의 차이점

CSR(Client Side Rendering)과 SSR(Server Side Rendering)의 차이점 1. 브라우저 렌더링 브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면(View)에 표시해주는 작업을 말한다. Chorme 같은 경우, 브라우저

junvelee.tistory.com

CSR(Client Side Rendering)의 단점

1) 사용자 경험성이 떨어진다 : CSR은 HTML문서가 비어있고, JS에 의해 HTML요소가 추가되는 형태이다. -> 초기 렌더링이나 새로고침 시 유저가 페이지를 처음 봤을 땐 빈 화면을 보게된다. JS가 다운로드되고 실행되면 그제서야 화면이 보이기 때문에 초기 렌더링이 오래걸린다. -> 만약 사용자의 네트워크가 느릴 경우, JS파일이 다운로드되고 실행될 때 까지 기다려야만 한다.

2) SEO(검색엔진)에 취약 하다 : 구글 검색엔진은 빈 HTML을 보게 되므로 정보를 얻을 수 없다(구글 검색엔진은 간혹 JS를 실행시킨다고 하지만 대부분의 검색엔진은 JS까지 실행시키지 않고 HTML를 분석한다.)

이와같은 CSR의 단점으로 최근 SSR의 필요성이 높아진것 같다.

SSR(Server Side Rendering)의 장점

1) SEO에 유리 : SSR은 서버에서 렌더링하여 완성된 HTML을 클라이언트에 전달한다. 이 때문에 모든 내용을 HTML이 가지고 있어 SEO에 유리하다.

2) 초기 렌더링 빠름 : 네트워크가 느리거나, JS가 실행되기 전에도 이미 사용자는 HTML을 통해 웹 페이지 내용을 확인할 수 있다. 초기 렌더링 시에도 유저가 빈화면을 볼 일이 없기 때문에 초기렌더링이 빠르다. 즉 모든컴포넌트 UI를 빌드하는데 JS에 의존적이지 않다.(다만 동적인 반응은 JS가 다운로드 된 후 일어나기 때문에 격차는 발생할 수 있다)

Next.js의 경우 SSR이지만 그 단점을 좀 더 보완시켰다. 아래에서 확인해 보자.

4. Hydration

SSR의 경우 모든 페이지를 서버에서 렌더링 하기 때문에 서버로부터 완성된 HTML을 받아 온다. 때문에 페이지 이동 시 새 페이지를 다시 요청하여 로딩 속도가 오래걸리고 깜빡임이 발생했다.

Next.js에서는 Hydration과정을 통해 이를 줄일수 있도록 하였다. 간단히 요약하면 다음과 같다.

사용자가 url 접속 -> 서버에서 렌더링된 HTML 전달 -> 클라이언트에서 HTML을 받아 바로 사용자에게 보여줌
-> 이와 함께 프레임워크가 즉시 JS를 load해서 초기 HTML 위에 React 컴포넌트로 초기화 시킴 -> React app을 생성함

Hydration은 단순한 HTML문서를 -> React app으로 초기화하는 작업을 뜻하며 클라이언트에서 이루어진다. 이 과정을 통해, 사용자는 초기 렌더링 시 빠르게 HTML문서를 확인 가능하면서도, 클라이언트 쪽에서 즉시 JS를 리액트 컴포넌트로 초기화하여 -> 페이지 이동시에도 reload없이 CSR과 같이 부드럽게 페이지를 이동시킬 수 있다. SSR의 단점이었던 페이지 이동시 느린 로딩 속도를 보완한 것이다.

5. 'use Client'

이전까지는 Next.js에서 모든 컴포넌트가 서버 컴포넌트(RSC)였기 때문에 서버에서 렌더링 되고, 또 모든 컴포넌트가 클라이언트 쪽에 JS번들로 전달되어 Hydration 되었다. 이말은 곧 클라이언트쪽에 넘겨지는 JS파일들이 많다는 뜻이고, 그만큼 페이지 이동시에도 (서버에서 새 페이지 렌더링 + 받는 JS파일이 많음) 로딩 속도가 많이 빠르지 못한 부분이 있었다.

❗주의) 클라이언트 컴포넌트 또한 서버에서 렌더링되는 것은 같다. 다만 클라이언트 쪽에도 JS를 전달하여 렌더링 -> Hydration 된다.(클라이언트 컴포넌트라고 해서 클라이언트에서만 렌더링되는 것이 아니라 '둘 다'에서 렌더링 된다.)

Next.js 13버전에서도 app 디렉토리를 구성하면 기본적으로 모두 서버 컴포넌트가 되며 서버에서 렌더링 된다. 하지만 이번에 'use Client'가 등장하면서 선택적으로 클라이언트 컴포넌트(RCC)로 만들어 특정 요소만 클라이언트에 전달하여 Hydrate 할 수 있게 되었다.

즉, 오직 "use Client"를 선언한 클라이언트 컴포넌트만 클라이언트 쪽에(전달된다)서 Hydrate되는 것이다.

이로 인해 달라진 점은, 서버 컴포넌트와 클라이언트를 선택적으로 적용 가능하게 되었고, JS 동적인 기능이 필요한 컴포넌트만 클라이언트 컴포넌트로 선언하여 서버 -> 클라이언트로 JS번들을 전달하여 Hydration(JS로 컴포넌트화)시킨다. 이렇게 하면 서버 컴포넌트는 더 이상 클라이언트에 JS번들이 전달되지 않고(서버 컴포넌트는 동적인 기능이 없기때문에 클라이언트에 전달될 필요가 없다), 클라이언트가 받는 JS번들은 오직 클라이언트 컴포넌트밖에 없기 때문에 이전에 비해 전달되는 JS파일들이 적고 페이지 로딩 속도가 더 빨라진다(페이지 이동, 새로고침 시 로딩 속도 문제 보완).

+ 어떤 컴포넌트를 클라이언트 컴포넌트('use Client')로 선언할지는 고민하지 않아도 된다. onClick, useState 등의 hooks, Link 등 reload, 동적인 동작을 할 경우 자동으로 'use Client'를 선언해야 한다고 에러를 띄워준다.

+ 서버 컴포넌트와 클라이언트 컴포넌트가 나뉘어짐으로서 서버컴포넌트는 더이상 클라이언트로 전달되지 않기 때문에 보안성이 높다.(API key, DB와 통신 가능 등)

6. 'Client Component' 내부에 'Server Component' ?

그렇다면 서버 컴포넌트와 클라이언트 컴포넌트를 섞어서 사용할 경우, 클라이언트 컴포넌트는 클라이언트로 전달된다고 했는데 클라이언트 컴포넌트가 서버 컴포넌트를 감싸고 있을 경우에는 어떻게 될까? 의문이 들 것이다.

기본적으로 클라이언트 컴포넌트의 자식은 모두 클라이언트 컴포넌트 모듈로 간주되어 클라이언트로 같이 전달된다. 하지만 이번에 변경되어 서버 컴포넌트를 클라이언트 컴포넌트의 props으로 전달하여 자식으로 배치시키면 가능하다고 한다.

자세한 내용은 공식문서를 참조하자.

<참조>

공식문서 및 nomadcoders의 Next.js 시작하기 강의로 공부한 후 정리한 내용입니다.

CSR(Client Side Rendering)과 SSR(Server Side Rendering)의 차이점

junvely — Thu, 14 Mar 2024 19:27:33 +0900

CSR(Client Side Rendering)과 SSR(Server Side Rendering)의 차이점

1. 브라우저 렌더링

브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면(View)에 표시해주는 작업을 말한다.

Chorme 같은 경우, 브라우저 엔진 내부에 렌더링 엔진(Blink)과 자바스크립트 엔진(V8) 이 존재한다.
렌더링 엔진에서는 HTML, CSS를 해석하고 비트맵 형식으로 웹 페이지를 화면에 그리는 역할을 하고,
자바스크립트 엔진에서는 자바스크립트 코드를 해석(*인터프리터)하고 실행하여 웹 페이지에 동적인 기능을 추가하고 상호작용 가능하게 한다.(자바스크립트=인터프리터, 타입스크립트=컴파일)
*참조 : JavaScript는 인터프리터 언어?

#00. JavaScript는 인터프리터 언어?

결론 : JavaScript는 (해석 엔진에 따라 컴파일하기도 하는) 인터프리터 언어로 볼 수 있다. Q. JavaScript는 인터프리터 언어라는데 맞나요? A. 결론부터 말씀드리자면 인터프리터 언어로 분류되지만

hwon-da.tistory.com

컴파일이란 무엇이며, 자바스크립트는 인터프리터 언어인가?

컴파일이란 무엇인가? 컴파일은 우리가 작성한 소스 코드를 오브젝트 코드로 변환시키는 과정이다. 인간이 알아듣기 쉬운 프로그래밍 언어인 High Level Language를 기계가 알아들을 수 있는 0과 1로

devlog-of-yein.tistory.com

브라우저의 렌더링 과정은 다음 포스팅을 참조하도록 하자.

브라우저의 구성 요소와 렌더링 과정

브라우저의 렌더링 원리 브라우저는 사용자 인터페이스, 브라우저 엔진, 렌더링 엔진, 네트워크, 자바스크립트 인터프리터, UI백엔드, 스토리지로 구성되어 있다. 브라우저가 화면을 렌더링 할

junvelee.tistory.com

브라우저 렌더링은 크게 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR) 방식으로 나누어진다.

2. 클라이언트 사이드 렌더링(CSR)

CSR은 "Client-Side Rendering"의 약어로, 클라이언트 측에서 페이지를 렌더링하는 방식을 말한다.

1. 사용자가 웹 사이트에 요청을 보내면 -> 서버로부터 빈 HTML페이지 + 모든 소스 코드들(JS포함)을 전달 받는다

= 웹 페이지에 필요한 많은 JS, 소스파일들을 다운로드 하고 해석하여 실행하기 까지 초기 렌더링 속도가 오래 걸린다. 사용자는 JS파일을 모두 다운로드 할 때 까지 빈 화면을 보고있어야 한다(새로고침 시에도)

2. 초기에 웹 페이지와 관련된 데이터를 모두 받기 때문에 -> 페이지 이동시 추가적으로 필요한 데이터만 서버로부터 json형식으로 받고 -> JS를 해석하여 동적으로 HTML을 생성해서 UI를 업데이트 한다.

= 네이티브앱과 같이 한 페이지 내에서 깜빡임 없이 부드러운 사용자 경험을 얻을 수 있다.

3. 검색엔진(SEO)은 서버의 HTML파일을 분석하는데, CSR에서는 초기 HTML문서의 body가 빈 페이지이고, 필요시 마다 JS로 동적으로 HTML을 생성하기 때문에 = SEO에 취약하다.(이전 크롤러들은 자바스크립트를 실행시키지 않았었기에 SEO 최적화가 필수적이었다. 구글이 그 트렌드를 바꾸고 있다고 한다.)

1. 사용자가 웹 사이트에 요청을 보낸다.
2. CDN이 HTML 파일과 JS로 접근 할 수 있는 링크를 클라이언트로 보낸다(CDN : aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식))
3. 클라이언트는 HTML과 JS를 다운로드 받는다.
4. 브라우저가 자바스크립트를 다운로드 받는다.
5. 다운로드가 완료된 JS가 실행이 되며 데이터를 위한 API가 호출이 된다.
6. 서버가 API로 부터의 요청에 응답한다.
7. API로부터 받아온 데이터를 placeholer 자리에 넣어주면, 페이지가 상호작용이 가능해진다.

CSR의 장점

높은 사용자 경험: CSR은 클라이언트 측에서 데이터를 받아와 렌더링하기 때문에 페이지 이동 속도가 빠르고, 깜빡임이 적어 사용자 경험이 높다.
캐싱 가능: 클라이언트에서 캐시를 사용하여 적은 양의 데이터만 다시 요청하여 처리하는 것이 가능하다.
적은 서버 부하: CSR에서는 클라이언트에서 데이터를 처리하기 때문에 서버 부하가 적다.

CSR의 단점

느린 초기 로딩 속도: CSR은 페이지를 렌더링하기 위해 필요한 JavaScript 파일을 먼저 다운로드한 후에 데이터를 받아와야 한다. 이로 인해 초기 로딩 속도가 느리게 느껴질 수 있다. (HTML은 JavaScript 파일을 포함하는데, 이 JavaScript 파일이 다운로드되고 실행될 때까지 렌더링되지 않은 상태로 남아 있다. 따라서 JavaScript 파일이 다운로드되고 실행될 때까지 페이지가 완전히 렌더링되지 않은 상태가 되며 이로 인해 초기 페이지 로딩 시간이 증가할 수 있다. 특히 JavaScript 파일이 크거나 네트워크 연결이 느린 경우에는 브라우저가 JavaScript 파일을 다운로드하고 실행하는데 시간이 걸릴 수 있으며, 그동안 사용자는 비어 있는 화면이나 로딩 스피너를 볼 수 있다)

SEO에 불리함: CSR에서는 초기 HTML 파일에 콘텐츠가 포함되어 있지 않기 때문에 검색 엔진이 페이지를 크롤링할 때 콘텐츠를 인식하지 못할 수 있다.
높은 개발 난이도(런닝커브): CSR은 대규모의 복잡한 웹 애플리케이션에서 많이 사용되며, 이를 구현하기 위해서는 높은 개발 난이도와 복잡성이 요구된다. 특히, 상태 관리와 라우팅 등을 구현하기 위해서는 추가적인 라이브러리나 프레임워크를 사용해야 한다.
낮은 보안성: CSR에서는 클라이언트에서 데이터를 처리하기 때문에 보안성이 낮을 수 있다. 클라이언트 측에서 데이터를 조작하거나 해킹 등의 공격이 가능하다.

CSR의 사용권장 예시

네트워크가 빠를 때
서버의 성능이 좋지 않을 때
사용자에게 보여줘야 하는 데이터의 양이 많을 때(로딩스피너 가능)
메인 스크립트가 가벼울 때
SEO의 영향을 비교적 덜 받는 웹 사이트
웹 어플리케이션에 사용자와 상호작용할 경우가 많을 때

3. 서버 사이드 렌더링(SSR)

SSR은 "Server-Side Rendering"의 약어로, 서버 측에서 페이지를 렌더링하는 방식이다.

1. 사용자가 웹 사이트에 요청을 보내면 -> 서버에서는 데이터들을 기반으로 즉시 렌더링 가능한 초기페이지 HTML를 먼저 완성 시킨다. -> 완성된 HTML 파일과 함께, 동적으로 제어 가능한 JS번들 등을 클라이언트에 전달한다

= 초기 렌더링이 빠르다. / 반면에 완성된 HTML파일은 즉시 렌더링 되지만, JS는 다운로드하고 실행하는데에 시간이 걸리기 때문에 동적인 기능을 수행하는데 까지의 격차가 생길 수 있다. 예를 들어 사용자가 UI를 클릭해도 동적인 조작이 일어나지 않을 수 있다(기억하고 있음).

2. 페이지 이동 시에는 다시 서버로부터 새 HTML 페이지를 요청하고 -> 완성된 HTML 페이지를 전달 받기 때문에

= 깜빡임이 발생하고, 사용자 경험성이 떨어진다. 또한 페이지 이동 시 마다 새 HTML문서를 서버에서 처리하기 때문에 서버요청이 많고, 부하가 증가할 수 있다.

3. HTML문서에 모든 컨텐츠가 담겨 있기 때문에 SEO 검색엔진에 더 효율적이다.

1. 사용자가 웹 사이트에 요청을 보낸다.
2. Server는 ‘Ready to Render’ 즉시 렌더링 가능한 html 파일을 만든다.
3. 클라이언트에 전달하는 순간 이미 렌더링 준비가 되었기 때문에 HTML이 즉시 렌더링이 된다. 하지만 사이트에서 조작은 불가능하다.(JavaScript가 읽히기 전)
4. 브라우저가 자바스크립트를 다운 받는다.
5. 다운로드가 이루어지고 있는 상태에서 사용자는 컨텐츠를 볼 수 있지만 사이트를 조작할 수 없다. 이때 사용자의 조작을 기억하고 있다.
6. 브라우저가 JavaScript FrameWork를 실행한다.
7. JS까지 성공적으로 컴파일되었기 때문에, 아까 기억하고 있던 사용자의 조작이 실행되고 웹 페이지는 상호작용이 가능해진다.

SSR의 장점

빠른 초기 로딩 속도: SSR은 서버 측에서 데이터를 받아와 렌더링하기 때문에 초기 로딩 속도가 빠르다.
SEO에 유리함: SSR에서는 초기 HTML 파일에 콘텐츠가 포함되어 있기 때문에 검색 엔진이 페이지를 크롤링할 때 콘텐츠를 인식할 수 있다.
높은 보안성: SSR에서는 서버 측에서 데이터를 처리하기 때문에 보안성이 높다. 클라이언트 측에서 데이터를 조작하거나 해킹 등의 공격이 어려워진다.
서버 부하를 분산 가능: SSR에서는 서버 측에서 데이터를 처리하기 때문에 서버 부하가 분산될 수 있다.
낮은 런닝 커브

SSR의 단점

느린 페이지 이동 속도: SSR은 페이지 이동할 때마다 서버에서 데이터를 받아와 렌더링해야 하기 때문에 페이지 이동 속도가 느리다.
낮은 사용자 경험: SSR에서는 페이지 이동 속도가 느리기 때문에 사용자 경험이 낮을 수 있다.
어려운 캐싱: SSR에서는 캐시를 사용하는 것이 어려울 수 있다. 매번 새로운 데이터를 불러와야 하기 때문에 서버 부하가 증가할 수 있다.
낮은 개발 난이도: SSR은 일반적인 웹 개발 방식과 유사하기 때문에 개발 난이도가 낮다. 하지만, 대규모의 복잡한 웹 애플리케이션에서는 추가적인 복잡성이 요구될 수 있다.

SSR을 사용 권장

네트워크가 느릴 때 (CSR은 한번에 모든 것을 불러오지만 SSR는 각 페이지마다 나누어 불러오기 때문이다)
SEO(Search engine Optimization) 검색 엔진 최적화가 필요할 때
최초 로딩이 빨라야 하는 사이트를 개발할 때
메인 스크립트가 크고 로딩이 엄청 느릴 때
(CSR은 메인스크립트가 로딩이 끝나면 API로 데이터 요청을 보내지만, SSR은 한번의 요청에 아예 렌더가 가능한 페이지가 돌아온다)
웹 사이트가 상호작용이 별로 없을 때

이상으로 SSR과 CSR에 대하여 알아봤다. React를 사용하면서 CSR의 치명적인 단점인 SEO와 초기렌더링 속도를 극복하기 위한 방안으로 최근에는 React meata-Framework들을 사용한다는 것을 알았다. 그 중 압도적인 만족도를 기록하고 있는 Next.js같은 경우는 SSR이면서도 그의 단점을 많이 보완시켰다고 할 수 있을 것 같다.

Next.js는 SSR를 지원하며 초기 렌더링 속도와 SEO에서 높은 성능을 보이면서도 SSG까지도 구현 가능하다. 또한 Next.js 13버전에서는 다양한 기능들이 추가되며 새로운 기술들을 접목시킬 수 있게 되었다. 그 중에서도 app 디렉토리가 도입되면서 app 디렉토리의 모든 컴포넌트는 React Server Components로서 공식적으로 지원되게 되었고, RSC(Server Component)와 RCC(Client Component)를 선택할 수 있다는 것이 가장 인상적이었다. 컴포넌트를 어느쪽에서 렌더링을 시킬지 결정할 수 있기 때문에 상황에 따라 개발이 가능하며 이것은 앱 성능에 큰 영향을 미칠 것이다.(하지만 RSC와 SSR은 서버에서 처리한다는 공통점 외에는 HTML문서가 아닌 컴포넌트라는 점 등 각각 해결하고자하는 목표도 다르고, 일어나는 시점과 최종 산출물도 다른 완전히 별개의 개념이라고 한다).

어찌됐든 Next.js를 공부하면서 React Sever Components를 이해하기 위해서는 기본적으로 CSR과 SSR에 대한 공부가 필요했다. 다음에는 RSC와 RCC에 대해 더 공부해 보도록 해야겠다. 아래 자료들은 Next.js의 13버전과 React Server Components에 대한 소개와 평가들이니 더 공부해 보고 싶을 때 읽어보면 좋을 것 같다. React와 함께 Type Script...Next.js... 공부할 것들이 한참 남았다..

[Next.js] Next.js Routing과 Hydronation, 'use Client' 알아보기

[Next.js] Next.js Routing과 Hydronation, 'use Client' 알아보기 Next.js에 대해 공부해보면서 알게된 내용들을 간단히 정리해 보고자 한다. 먼저 React는 라이브러리이고, Next.js는 프레임워크이다. 학습하면서

junvelee.tistory.com

[번역] React Server vs Client Component in Next.js 13

원 글 링크Next.js 에서, 너는 리액트 서버 컴포넌트와 클라이언트 컴포넌트를 사용할 수 있다. app 경로에서 기본적으로 모든 컴포넌트들은 서버 컴포넌트이다. 이 게시글에서, 우리는 리액트 서

velog.io

Next) 서버 컴포넌트(React Server Component)에 대한 고찰

이번에 회사에서 신규 웹 프로젝트를 진행하기로 결정했는데, 정말 뜬금 없게도 앱 개발자인 내가 이 프로젝트를 리드하게 되었다. 사실 억지로 떠맡게 된 것은 아니고, 새로운 웹 기술 스택을

velog.io

[Frontend] React와 Next.js의 차이? / Next.js의 필요성 / Next.js 13버전 변경점

React와 Next.js의 차이 React는 Javascript 기반의 SPA 웹 프레임워크입니다. 컴포넌트를 활용하여 UI를 쉽고 효율적으로 만들 수 있습니다. 이 글에서 강조하고자 하는 내용은 리액트는 CSR(Client Side Render

yeongjaekong.tistory.com

React 의 RSC, RCC 에 대하여 (with Next.js)

React 18 버전이 출시 된 후 Next.js 에서는 app dir 기능이 도입되어 React 의 RSC, RCC 기능을 사용할 수 있게 되었습니다. 이번 포스트에서는 최근 화두인 RSC, RCC 에 대해 한번 정리해보고자 합니다. RSC

funveloper.tistory.com

<참고>

클라이언트 사이드 렌더링(CSR) vs 서버 사이드 렌더링(SSR)

브라우저 렌더링이란? 브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면(View)에 표시해주는 작업을 말한다. 브라우저가 서버로부터 HTML, CSS, JavaScript 문서를 전달받아 브라우저 엔진이

suzzeong.tistory.com

SSR, CSR

SSR | Server Side Rendering말 그대로 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이어트에 전달하는 방식User가 Website 요청을 보냄.Server는 'Ready to Render'. 즉, 즉시 렌더링 가능한 html파일을 만든다.(

velog.io

[TypeScript] 타입스크립트란 무엇인가? 타입스크립트 동작 원리에 대하여

junvely — Fri, 8 Mar 2024 21:18:18 +0900

TypeScript 란 무엇인가?

1. Javascript의 한계

모든 언어에는 타입 시스템이 존재하며, 크게 정적 타입 시스템과 동적 타입 시스템으로 나뉘어 진다.

각각의 특징은 다음과 같다.

1) 동적 타입 시스템 = JavaScript, Python

- 타입을 미리 검사하지 않는다.

- 개발자의 의도치 않은 타입 실수로 인해 치명적인 오류가 발생할 가능성이 높다.

-> 타입을 미리 검사하지 않기 때문에 타입 오류 시에도 실행이 바로 중단되지 않는다. 때문에 개발자의 타입 실수 시 런타임 중 하루뒤, 한달 뒤 등 예기치 못할 때 갑작스럽게 에러가 발생하는 등 잘 돌아가던 프로그래밍이 갑자기 실행이 안된다던지 치명적인 오류가 발생할 수 있고 디버깅이 힘들다.

2) 정적 타입 시스템 = C, Java

- 타입을 미리 검사하며, 타입과 관련된 문제 발생 시 즉시 에러를 반환하며 실행이 중단된다.

- 개발자의 타입 실수 시, 즉시 실행이 중단되므로 예상지 못한 실수 발생을 막을 수 있다.

- 하지만 모든 변수에 타입을 지정해야 함으로 타이핑양이 굉장히 많아지고 번거롭다(자바스크립트의 장점인 유연함이 x).

3) Javascript의 한계

자바스크립트는 동적 타입 시스템으로, 개발자의 타입 실수 시 즉시 실행이 중단되지 않기 때문에 언젠가 예상치 못한 치명적인 문제가 발생할 가능성이 높다!

2. TS의 타입 시스템 = 점진적 타입 시스템

- 타입스크립트는 독특한 타입 시스템인 '점진적 타입 시스템'이다.

- 정적 + 동적 시스템의 장점들을 가지고 있다.

-> 정적 타입 시스템과 같이 실행 전 타입을 검사하여 안정성을 확보하며, 일일히 모든 변수에 타입을 지정하지 않아도 변수에 담기는 초기값을 기준으로 자동으로 변수의 타입을 추론하는 유연함을 가지고 있다.

따라서 타입스크립트는 점진적 타입 시스템을 채택해서 정적 타입 시스템처럼 프로그램 실행 전에 타입을 올바르게 썼는지 타입 검사를 해 타입 안정성을 확보하면서도 동적 타입 시스템처럼 변수에 우리가 일일히 모두 다 타입을 지정해주지 않아도 되는 유연함까지 확보한 독특한 타입 시스템을 갖추고 있는 똑똑한 언어라는 것이다.

TypeScript 의 동작원리

1. 대다수 언어가 동작하는 과정

- 컴퓨터는 프로그래밍 언어 코드를 컴퓨터가 해석하기 쉬운 기계어=(바이트 코드) 형태로 변환 하는데 이 과정을 우리는 컴파일이라고 부른다.

2. 컴파일 과정

- 컴파일러는 프로그래밍 언어를 바로 바이트코드로 변환하는게 아니라 그 전에 AST(추상 문법 트리)라는 특별한 형태로 먼저 변환한다. AST는 추상 문법 트리 라는 뜻이다.

- 프로그래밍 언어 -> AST 추상 문법 트리 -> 바이트 코드

아래는 AST(추상 문법 트리)를 간략하게 나타낸다.

- AST(추상 문법 트리)는 코드의 공백이나 주석 탭 등의 코드 실행에 관계없는 그런 요소들은 전부 제거하고 트리 형태의 자료구조에 코드를 쪼개서 저장 해 놓은 그런 형태이다.

- 이렇게 코드를 AST로 변환하고 나면 -> 컴파일러가 AST를 -> 바이트코드로 변환하고 컴파일이 종료된다.

3. 타입스크립트의 컴파일 과정

- 우선 다른 언어들과 동일하게 먼저 타입스크립트 코드를 AST로 변환한다.

- 그 다음 AST를 -> 바이트코드로 변환하는게 아니라 이 AST를 보고 코드 상 타입 오류가 없는지 타입 검사를 수행한다.

이때 코드에 타입 오류가 있으면 타입 검사 실패 -> 컴파일이 중단된다.

만약 타입 오류가 없는 정상적인 코드라면 타입 검사 성공 -> AST를 바이트코드가 아닌, ‘자바스크립트 코드’로 변환하고 컴파일이 종료된다.

이렇게 타입스크립트의 컴파일 결과로 만들어진 자바스크립트 코드를 Node.js나 웹브라우저로 실행하면 앞서 살펴본 대다수의 언어들과 동일한 과정을 거쳐 컴파일 되어 실행된다.

타입스크립트 코드의 컴파일 과정에 타입 검사가 포함되어 있기 때문에 타입 스크립트 코드를 컴파일 해서 생성한 자바스크립트 코드는 타입 검사를 통과한 타입 오류가 발생할 가능성이 낮은 자바스크립트 코드인 것이다.

✨ 타입스크립트 컴파일 과정 정리

타입스크립트 코드 -> AST 추상 문법 트리 변환 -> 타입 검사(실패시 컴파일 종료) -> 자바스크립트 언어로 변환
-> 안전한 자바스크립트 코드 -> AST 추상 문법 트리 -> 바이트 코드 변환 -> 실행

+ 타입스크립트 컴파일러에 관하여 실습해 보기

타입스크립트 컴파일러 사용법 (tsc 커맨드)

Engineering Blog by Dale Seo