Dorong Dorong 💻😴

오늘은 제가 Context API에서 Zustand로 상태관리 도구를 전환하게 된 과정과 2024년 현재 리액트 상태관리 라이브러리들의 현황에 대해 이야기해보려 합니다.

1. Context API의 한계와 상태관리 라이브러리의 필요성

Context API로 시작한 이유

처음 알리니 프로젝트를 시작할 때는 Context API만으로 충분하다고 생각했습니다. 사용자 인증, 테마, 언어 설정 등 전역적으로 공유되어야 하는 상태들을 관리하는 데 Context API 만으로 충분했습니다.

// 초기 Context API 사용 예시
const PetContext = React.createContext<PetContextType | undefined>(undefined);

export const PetProvider: React.FC<PropsWithChildren> = ({ children }) => {
  const [petData, setPetData] = useState<PetData>({
    allergies: [],
    symptoms: [],
    foodLog: []
  });

  return (
    <PetContext.Provider value={{ petData, setPetData }}>
      {children}
    </PetContext.Provider>
  );
};

한계점 발견

하지만 프로젝트가 커지면서 여러 가지 한계점이 드러나기 시작했습니다:

• 불필요한 리렌더링: Context의 값이 변경될 때마다 해당 Context를 구독하는 모든 컴포넌트가 리렌더링되었습니다. 
• 코드 복잡도 증가: 여러 개의 Context를 중첩해서 사용하다 보니 Provider Hell이 발생했습니다.
• 상태 업데이트 로직 관리의 어려움: 비동기 작업과 복잡한 상태 업데이트 로직을 처리하는 데 한계가 있었습니다.

2. 주요 상태관리 라이브러리 비교 분석

Redux

Redux는 오랫동안 리액트 생태계의 표준과 같은 상태관리 라이브러리 입니다.

Redux의 핵심 개념

• Action: 상태 변경을 위한 이벤트를 설명하는 객체
• Reducer: Action을 받아 상태를 변경하는 순수 함수
• Store: 애플리케이션의 전체 상태를 보관하는 객체

Redux 미들웨어 생태계

• Redux Thunk: 비동기 작업을 처리하기 위한 가장 기본적인 미들웨어
• Redux Saga: 복잡한 비동기 흐름을 제어하기 위한 미들웨어
  • Generator 함수를 사용한 선언적 비동기 처리
  • 복잡한 시나리오(API 요청 취소, 재시도 등) 처리 가능
• Redux Toolkit: 보일러플레이트 코드를 줄이기 위한 공식 도구

그러나 Redux는 다음과 같은 단점이 있습니다:

• 많은 보일러플레이트 코드
• 학습 곡선이 가파름
• 작은 상태 변화에도 많은 코드 필요

Recoil

Facebook에서 만든 상태관리 라이브러리입니다.

장점

• React와의 높은 호환성
• 간단한 API (atom, selector)
• 비동기 데이터 처리가 쉬움

단점

• 아톰으로 관리되는 전역 상태를 어떤 컴포넌트라도 바로 아톰을 구독해서 업데이트를 받기에, 의존성이 여러 방향으로 엮이면서 예측하기 힘들어집니다.

Zustand

가볍고 직관적인 API를 제공하는 현대적인 상태관리 라이브러리입니다.

주요 특징

• 최소한의 보일러플레이트
• TypeScript 지원이 훌륭함
• Redux DevTools 지원
• 미들웨어 시스템 (persist, devtools 등)

예시 코드:

import create from 'zustand'

interface PetStore {
  symptoms: Symptom[]
  addSymptom: (symptom: Symptom) => void
  foodLogs: FoodLog[]
  addFoodLog: (log: FoodLog) => void
}

const usePetStore = create<PetStore>((set) => ({
  symptoms: [],
  addSymptom: (symptom) => set((state) => ({
    symptoms: [...state.symptoms, symptom]
  })),
  foodLogs: [],
  addFoodLog: (log) => set((state) => ({
    foodLogs: [...state.foodLogs, log]
  }))
}))

3. 실제 프로젝트에서의 선택: Zustand

알리니 프로젝트에서의 요구사항

1. 실시간 데이터 업데이트
2. 복잡한 상태 관리 (알레르기 증상, 음식 기록, 분석 데이터)
3. 성능 최적화
4. TypeScript 지원

Zustand 선택 이유

1. 간단한 설정과 사용법: 별도의 Provider 설정이 필요 없고, 직관적인 API를 제공합니다.
2. 성능 최적화: 필요한 상태만 구독하여 불필요한 리렌더링을 방지합니다.
3. TypeScript 지원: 타입 추론이 잘 동작하여 개발 생산성이 향상되었습니다.
4. 미들웨어 지원: persist 미들웨어를 통해 로컬 스토리지 연동이 쉬웠습니다.

Context API와의 조화

Context API와 Zustand를 함께 사용할 수 있습니다. 저는 다음과 같이 역할을 구분했습니다:

• Context API: 테마, 인증 등 애플리케이션의 전반적인 설정과 관련된 상태 관리 (단어 그대로 특정 맥락을 씌울때 사용했습니다.)
• Zustand: 비즈니스 로직과 관련된 복잡한 상태 관리

4. 결론

2024년 현재, 저는 다음과 같은 기준으로 상태관리 라이브러리를 선택했습니다:

1. 작은 프로젝트: Context API만으로도 충분
2. 중간 규모 프로젝트: Zustand
3. 대규모 프로젝트: Redux Toolkit 또는 Zustand

알리니와 같이 실시간 데이터 처리와 복잡한 상태 관리가 필요한 프로젝트에는 Zustand가 특히 적합했습니다. 코드가 간결하면서도 강력한 기능을 제공하며, 특히 TypeScript와의 호환성이 뛰어나 개발 경험이 매우 좋았습니다.

프론트엔드 개발을 하다 보면 크로스브라우징 이슈는 피할 수 없습니다.

::-webkit-input-placeholder와 같은 브라우저별 프리픽스(-webkit-, -moz-, -ms- 등)를 일일이 추가하는 건 굉장히 번거로운 작업이예요.

사실 현업에서는 개발자가 직접 이러한 프리픽스를 추가하는 것이 매우 곤란한 일입니다.

(저도 관련된 대화를 나누다 알게됐어요!)

이러한 문제를 해결하기 위해 번들러를 통해 자동으로 프리픽스를 추가해주는 방법인 Autoprefixer를 사용할 수 있습니다.

PostCSS를 기본적으로 사용하는 라이브러리라면, 혹은 CSS로 변환한 후 postcss-loader가 처리하게 한다면 개발자가 각 브라우저 환경에 맞게 스타일을 따로 작성하지 않아도 Autoprefixer가 웹킷 프리픽스와 같은 것을 자동으로 붙여줍니다.

이번 포스트에서는 PostCSS와 Autoprefixer를 활용해 해당 ISSUE를 해결하는 방법을 실제 프로젝트 경험을 바탕으로 상세히 알아보겠습니다!

PostCSS와 Autoprefixer란?

PostCSS

• JavaScript 플러그인을 사용해 CSS를 변환하는 도구
• "Post-processor"라고도 불리는 이유는 CSS를 작성한 후에 처리하기 때문
• CSS 구문 분석에 최적화된 파서를 사용해 높은 성능을 보임
• CSS 전처리기(Sass)나 후처리기로 사용 가능 (이 부분은 제가 헷갈렸던 부분이라 아래 추가설명을 넣었어요!)
  1. CSS 전처리기(SASS):
     CSS 기능을 확장한 언어 입니다. 변수, 중첩 규칙, 믹스인 등을 지원하고, PostCSS는 Sass로 작성한 코드를 처리할 수 있지만, PostCSS 자체는 Sass 문법을 사용하진 않아요.
  2. CSS 후처리기:
     PostCSS는 CSS코드가 작성된 후에 추가적인 변환 작업을 수행하는 도구로 사용될 수 있습니다.
     예를 들어, 제가 지금 작성하는 Autoprefixer 같은 플러그인을 사용해서 자동으로 브라우저 프리픽스를 추가할 수 있는 것처럼요!
• 200개 이상의 플러그인으로 다양한 기능 제공 (생태계가 큽니다!)
• 모듈화된 구조로 필요한 기능만 플러그인으로 선택적 추가 가능

Autoprefixer

• PostCSS의 대표적인 플러그인
• 브라우저 프리픽스를 자동으로 추가해주는 도구
• Browserslist 설정을 통해 지원 브라우저 범위 지정 가능

Create React App과 Vite의 기본 지원

해당 부분은 Webpack을 직접 설정하지 않을 땐 어떻게 되는 건지, 기본 설정이 되어 있는지 등이 궁금해 찾아보게 됐습니다.

Create React App (CRA)

• PostCSS와 Autoprefixer가 기본으로 설정되어 있음
• 별도 설정 없이 바로 사용 가능
• browserslist 설정도 기본 제공

CRA의 package.json을 보시면 아래와 같은 코드를 확인하실 수 있습니다.

"browserslist": {
  "production": [
    ">0.2%",
    "not dead",
    "not op_mini all"
  ],
  "development": [
    "last 1 chrome version",
    "last 1 firefox version",
    "last 1 safari version"
  ]
}

Vite

• PostCSS는 기본 지원
• Autoprefixer는 별도 설치 필요

yarn add -D autoprefixer

// vite.config.js
import autoprefixer from 'autoprefixer'

export default {
  css: {
    postcss: {
      plugins: [
        autoprefixer()
      ]
    }
  }
}

현재 프로젝트에 Custom Webpack 설정하기

커스텀 Webpack 설정에서는 수동으로 PostCSS와 Autoprefixer를 설정해야 합니다.

필요한 패키지 설치

yarn add -D postcss postcss-loader autoprefixer

웹팩 설정 예시

module.exports = {
  module: {
    rules: [
      {
        test: /\.module\.scss$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              modules: {
                localIdentName: "[name]__[local]--[hash:base64:5]",
              },
              importLoaders: 2,
            },
          },
          {
            loader: "postcss-loader",
            options: {
              postcssOptions: {
                plugins: [
                  ["autoprefixer"]
                ],
              },
            },
          },
          "sass-loader",
        ],
      },
      {
        test: /\.(scss|css)$/,
        exclude: /\.module\.scss$/,
        use: [
          "style-loader",
          {
            loader: "css-loader",
            options: {
              importLoaders: 2,
            },
          },
          {
            loader: "postcss-loader",
            options: {
              postcssOptions: {
                plugins: [
                  ["autoprefixer"]
                ],
              },
            },
          },
          "sass-loader",
        ],
      },
    ],
  },
  // ... 기타 웹팩 설정
};

실수했던 부분과 해결 방법

package.json에 작성돼야 하는 json 문법을. browserslistrc 파일에 적용해 버렸어요. 공식 문서를 읽다 순간적으로 착각했습니다. 너무 간단하지만 제 기준에서 치명적인 실수란 생각이 들어 기록해두려 합니다!

Browserslist 설정 오류

Error [BrowserslistError]: Unknown browser query `{`. Maybe you are using old Browserslist or made typo in query.

.browserslistrc 파일 사용 (권장)

저는 최종적으로 아래의 코드로 수정했습니다!

# 프로덕션 환경
[production]
>0.2% # 전 세계 사용률 0.2% 이상인 브라우저
not dead # 공식 지원이 중단되지 않은 브라우저
not op_mini all # Opera Mini 브라우저 제외

# 개발 환경
[development]
last 1 chrome version # 최신 크롬 버전
last 1 firefox version # 최신 파이어폭스 버전
last 1 safari version # 최신 사파리 버전

해결방법 2: package.json에 설정

{
  "browserslist": {
    "production": [
      ">0.2%",
      "not dead",
      "not op_mini all"
    ],
    "development": [
      "last 1 chrome version",
      "last 1 firefox version",
      "last 1 safari version"
    ]
  }
}

Browserslist 설정 가이드

주요 쿼리 설명

• >0.2%: 전 세계 사용률 0.2% 이상인 브라우저
• not dead: 공식 지원이 중단되지 않은 브라우저
• not op_mini all: Opera Mini 브라우저 제외
• last 1 chrome version: 최신 크롬 버전
• last 2 versions: 각 브라우저의 최신 2개 버전
• > 1%: 전 세계 점유율 1% 이상
• IE 11: IE 11 지원

설정 테스트

• browserslist.dev에서 설정을 테스트할 수 있음
• 어떤 브라우저가 포함되는지 실시간으로 확인 가능

실제 동작 예시

변환 전 CSS

.example {
  display: flex;
  user-select: none;
}

변환 후 CSS

.example {
  display: -webkit-box;
  display: -ms-flexbox;
  display: flex;
  -webkit-user-select: none;
     -moz-user-select: none;
      -ms-user-select: none;
          user-select: none;
}

주의사항과 팁!

• 로더 순서: PostCSS 로더는 Sass 로더 이후, CSS 로더 이전에 위치해야 합니다.  
  1. sass-loader (SCSS -> CSS 변환)
  2. postcss-loader (자동 프리픽스 추가)
  3. css-loader (CSS -> JS 변환)
  4. style-loader (JS -> style 태그 삽입)
• 성능 최적화: development 환경에서는 source map을 활성화하고, production에서는 비활성화하는 것이 좋습니다.
• 브라우저 지원 범위: browserslist 설정을 통해 지원할 브라우저 범위를 적절히 조절해야 합니다.

주의사항과 팁에서의 Development 환경에서 source map 활성화하는 이유 & Production 환경에서 비활성화 하는 이유에 대해서만 좀 더 자세히 알아볼게요!

Development 환경에서 source map 활성화하는 이유:

1. 디버깅 용이성
   • 개발 중에는 원본 소스 코드와 변환된 코드를 매핑하여 쉽게 디버깅할 수 있습니다
   • 브라우저의 개발자 도구에서 실제 작성한 CSS 파일의 위치와 라인을 정확히 확인 가능
   • PostCSS로 변환된 코드가 아닌 원본 코드를 직접 확인하며 수정 가능
2. 개발 효율성
   • 코드 수정 시 즉각적인 피드백 확인 가능
   • CSS 문제 발생 시 정확한 위치 추적이 가능하여 수정 시간 단축
   • 복잡한 스타일 구조에서도 원본 코드 위치를 쉽게 파악!

Production 환경에서 source map 비활성화하는 이유:

1. 파일 크기 최적화
   • source map 파일은 원본 코드와 변환된 코드의 매핑 정보를 포함하므로 상당한 크기를 차지
   • 프로덕션 환경에서는 불필요한 데이터 전송을 줄여 로딩 속도 향상
   • 일반적으로 source map 파일은 원본 파일 크기의 절반 이상을 차지할 수 있음
2. 보안 강화
   • source map이 노출되면 원본 코드 구조가 드러날 수 있음
   • 악의적를 가진 사용자가 코드 구조를 분석하는 것을 방지
   • 기업의 proprietary 코드 보호!!
3. 성능 최적화
   • 브라우저가 source map을 처리하는 추가적인 작업 제거
   • 초기 페이지 로딩 시간 단축
   • 서버 대역폭 사용량 감소

실제 설정 예시! (프로젝트 코드보다 간략화)

// webpack.config.js
module.exports = {
  mode: process.env.NODE_ENV,
  module: {
    rules: [{
      test: /\.css$/,
      use: [
        'style-loader',
        {
          loader: 'css-loader',
          options: {
            sourceMap: process.env.NODE_ENV === 'development'
          }
        },
        {
          loader: 'postcss-loader',
          options: {
            sourceMap: process.env.NODE_ENV === 'development'
          }
        }
      ]
    }]
  }
};

결론

PostCSS와 Autoprefixer를 사용하면 크로스브라우징을 위한 수동 작업을 자동화할 수 있습니다.

CRA나 Create Vite같은 경우 이미 이러한 기능을 기본으로 제공하고 있으며, 커스텀 웹팩 설정에서도 간단한 설정만으로 동일한 기능을 사용할 수 있습니다.

특히 Browserslist 설정을 통해 프로젝트의 브라우저 지원 범위를 명확히 하고, 필요한 프리픽스만 추가함으로써 최적화된 CSS를 생성할 수 있겠죠?!

.browserslistrc 파일을 사용하면 설정 관리가 더욱 용이해지며, 다른 도구들과도 설정을 공유할 수 있습니다.

여기서 "다른 도구들"은 주로 다음과 같은 CSS 또는 JavaScript 도구들을 의미합니다!

1. Autoprefixer: CSS에 필요한 브라우저 프리픽스를 자동으로 추가해주는 도구로, Browserslist 설정을 통해 어떤 프리픽스를 추가할지 결정 (지금까지 설명드린 내용이죠?!)
2. Babel: 최신 JavaScript 코드를 구형 브라우저에서도 작동할 수 있게 변환해주는 도구로, Browserslist 설정을 통해 지원할 브라우저 정의 가능
3. ESLint: JavaScript 코드의 품질을 관리하는 도구로, Browserslist와 함께 사용해 특정 브라우저 환경에 맞는 코드 스타일 적용 가능
4. Stylelint: CSS 스타일을 검사하는 도구로, Browserslist 설정을 참고하여 브라우저 호환성 관련 규칙 적용 가능

즉, .browserslistrc 파일을 사용하면 이러한 다양한 도구들이 동일한 브라우저 지원 범위를 공유하게 되어, 개발 및 유지보수 과정에서 일관성을 유지할 수 있습니다!

안녕하세요! express-openapi-validator의 HTTP 인증 관련 이슈를 해결하기 위해 PR을 제출했던 과정을 공유드리려고 합니다.

이전 포스트에서 express-openapi-validator를 사용하면서 발견한 인증 관련 이슈를 다뤘었는데요, 간단히 요약드리면:

Express.js로 REST API를 구축하며 JWT를 http-only 쿠키로 전달하려 했는데,
Authorization 헤더와 CSRF 토큰 검증에서 문제가 발생했습니다.

특히 validateHttp() 메서드가 Authorization 헤더를 필수로 요구하는 바람에,
쿠키로 JWT를 전달하는 상황에서도 헤더가 필요한 상황이 됐죠.

코드를 분석해보니 SecuritySchemes와 AuthValidator 클래스의 validateHttp 메서드에서 이 로직을 처리하고 있었고,
type: http로 설정된 스킴에서 Authorization 헤더를 강제하고 있었습니다.

이 문제를 해결하기 위해 Pull Request를 제출했고, 여러 번의 코드 리뷰와 수정 과정을 거쳐 마침내 Merge가 되어 express-openapi-validator의 Contributor가 된 여정을 오늘 상세히 공유드리려고 합니다! 🎉

🎯 첫 번째 시도: 쿠키 지원 추가

처음에는 단순히 Authorization 헤더 외에도 쿠키를 통한 인증을 지원하도록 다음과 같이 코드를 수정했습니다:

if (!authHeader && !authCookie) {
  throw Error(`Authorization header or cookie required`);
}

if (type === 'bearer') {
  if (authHeader && !authHeader.includes('bearer')) {
    throw Error(`Authorization header with scheme 'Bearer' required`);
  }

  if (!authHeader && authCookie === undefined) {
    throw Error(`Bearer token required in authorization header or cookie`);
  }
}

💡 코드 리뷰 피드백

제가 제출한 PR에 대해 메인테이너께서 중요한 피드백을 주셨습니다:

1. OpenAPI 명세에 따르면, in: cookie로 지정된 경우와 그렇지 않은 경우를 구분해야 함
2. 에러 메시지도 각각의 상황에 맞게 다르게 처리되어야 함
   • 일반적인 경우: "Authorization header required"
   • 쿠키 인증의 경우: "Cookie authentication required"

🔨 두 번째 시도: 명세 기반 수정

피드백을 반영하여 코드를 수정했지만, 여기서 또 하나의 실수가 있었습니다. 바로 프로젝트의 기존 코드 스타일을 해치는 변경사항이 포함된 것이었죠..

예를 들어 함수 시그니처나 들여쓰기, 괄호 위치 등이 프로젝트의 기존 스타일과 달랐죠.

// 제가 수정한 코드
function extractErrorsFromResults(
  results: (SecurityHandlerResult | SecurityHandlerResult[])[],
) {
  return results
    .map((result) => {
      if (Array.isArray(result)) {
        return result.map((it) => it).filter((it) => !it.success);
      }
      return [result].filter((it) => !it.success);
    })
    .flatMap((it) => [...it]);
}

// 원래 프로젝트 스타일
function extractErrorsFromResults(results: (SecurityHandlerResult | SecurityHandlerResult[])[]) {
  return results.map(result => {
    if (Array.isArray(result)) {
      return result.map(it => it).filter(it => !it.success);
    }
    return [result].filter(it => !it.success);
  }).flatMap(it => [...it]);
}

이를 빠르게 원래 프로젝트의 스타일대로 되돌리고 커밋을 추가했습니다.

하지만 여기서 끝이 아니었죠. CI 파이프라인에서 테스트를 돌려보니 두 가지 심각한 문제가 발견되었습니다:

🐛 테스트 실패 발견

이후 CI에서 두 가지 테스트가 실패한다는 것을 발견했습니다:

1. Basic 인증에서 헤더가 없을 때 발생하는 에러
2. undefined.includes() 호출로 인한 에러

AssertionError: expected 'Cannot read properties of undefined (…' 
to equal 'Authorization header required'

결론은 authHeader가 undefined일 때 발생하는 에러 메시지 문제로 인한 테스트 실패였습니다.

✨ 최종 해결책

모든 피드백과 테스트 케이스를 고려하여 다음과 같이 코드를 최종 수정했습니다:

private validateHttp(): void {
  if (['http'].includes(scheme.type.toLowerCase())) {
    const authHeader = req.headers['authorization']?.toLowerCase();
    const authCookie = req.cookies[scheme.name] || req.signedCookies?.[scheme.name];

    const type = scheme.scheme?.toLowerCase();
    if (type === 'bearer') {
      if (authHeader && !authHeader.includes('bearer')) {
        throw Error(`Authorization header with scheme 'Bearer' required`);
      }
      
      if (!authHeader && !authCookie) {
        throw Error(scheme.in === 'cookie' 
          ? `Cookie authentication required`
          : `Authorization header required`);
      }
    }

    if (type === 'basic') {
      if (!authHeader) {
        throw Error(`Authorization header required`);
      }
      if (!authHeader.includes('basic')) {
        throw Error(`Authorization header with scheme 'Basic' required`);
      }
    }
  }
}

주요 개선사항:

1. Basic 인증과 Bearer 인증의 명확한 구분
2. 쿠키 기반 인증 지원 (OpenAPI 명세 준수)
3. 적절한 에러 메시지 처리
4. undefined 체크 강화

🎓 배운 점

1. OpenAPI 명세를 더 꼼꼼히 살펴봐야 했습니다
2. 프로젝트의 전체 테스트 실행의 중요성을 다시 한번 깨달았습니다
3. 코드 스타일 가이드를 준수하는 것의 중요성을 배웠습니다

이렇게 해서 express-openapi-validator에 작은 기여를 할 수 있었네요. 오픈소스 기여는 언제나 새로운 배움의 기회인 것 같습니다.

다음에는 또 어떤 재미있는 문제를 해결하게 될지 기대가 됩니다! 😊

들어가며

최근 Allini 프로젝트를 진행하면서 몇 가지 고민이 생겼습니다.

over-fetching, waterfall 현상으로 인한 성능 저하, 그리고 무엇보다 빠른 시장 검증을 위해 다양한 라이브러리를 활용해야 하는 상황에서 발생하는 번들 사이즈 증가 문제였죠.

좋은 개발자는 단순히 모든 것을 손수 처음부터 구현하는 것이 아니라, 적절한 라이브러리를 선택하고 조잡해 빠르게 제품을 만들어내는 능력이 중요하다고 생각합니다.

하지만 이러한 접근은 필연적으로 번들 사이즈 증가라는 문제를 동반하게 되었고, 이는 제가 React 서버 컴포넌트에 관심을 갖게 된 주된 계기가 되었습니다!

1. React 서버 컴포넌트의 현재 사용 가능 여부

현재 상태

• React 18 버전: 서버 컴포넌트 미지원
• React 19 RC(Release Candidate): 서버 컴포넌트 지원

하지만 현재 React 18.2.0을 사용중인 프로젝트에서 서버 컴포넌트를 직접 사용하기는 어렵습니다.

React 19로의 업그레이드를 고려해볼 수 있지만, RC 버전이기 때문에 프로덕션 환경에서의 사용은 신중히 결정해야 합니다.

2. SSR과 서버 컴포넌트의 관계

SSR (Server-Side Rendering)

• 목적: 초기 페이지 로드 성능 개선 및 SEO 최적화
• 동작 방식:
  • 서버에서 전체 페이지의 초기 HTML을 생성
  • 클라이언트로 HTML과 JS 번들을 전송
  • 클라이언트에서 hydration 과정을 통해 인터랙티브한 앱으로 전환

이전 React 공식 문서에 따르면, React의 서버 사이드 렌더링 메서드들은 크게 세 가지 환경으로 구분됩니다:

Node.js Streams 환경용:

• renderToPipeableStream()
• renderToNodeStream() (Deprecated)
• renderToStaticNodeStream()

Web Streams 환경용 (브라우저, Deno, modern edge runtimes):

• renderToReadableStream()

스트림을 지원하지 않는 환경용:

• renderToString()
• renderToStaticMarkup()

기존 SSR의 동작 방식은 아래와 같습니다.

// 기존 SSR의 동작 방식
// 1. 서버에서 초기 렌더링
const app = ReactDOMServer.renderToPipeableStream(<App />);
// 한번에 전체 HTML을 생성하여 클라이언트로 전송

// 2. HTML 문서에 삽입
const html = `
  <!doctype html>
  <html>
    <body>
      <div id="root">${app}</div>
      <script src="/bundle.js"></script>
    </body>
  </html>
`;

공식 문서에 따르면, renderToPipeableStream을 통해 초기 셸(shell)을 렌더링하고 전송합니다.

renderToPipeableStream의 기본 개념은 아래와 같습니다.

• Node.js 환경에서 React 트리를 HTML 스트림으로 변환하는 API입니다.
• 점진적인 로딩이 가능한 스트리밍 SSR을 구현할 수 있습니다.

예시 코드

// 발전된 SSR (스트리밍 방식)
const { pipe } = renderToPipeableStream(<App />, {
  bootstrapScripts: ['/main.js'],
  onShellReady() {
    // 1. 먼저 기본 뼈대(shell)를 보냄
    // 초기 shell(Suspense 경계 위의 콘텐츠)이 준비되면 스트리밍 시작

    pipe(response);
  },
  onAllReady() {
    // 모든 콘텐츠가 준비되면 호출 (크롤러나 정적 생성용)
  }
});

기존의 renderToString은 제한적인 기능을 제공하는 반면, renderToPipeableStream은 Suspense를 완전히 지원하고 HTML 스트리밍이 가능한 더 발전된 형태의 SSR 방식입니다.

주요 차이점:

• 기존 SSR: 모든 데이터를 다 모아서 한번에 보냄 (느림)
• 새로운 SSR:
  1. 먼저 페이지의 기본 뼈대를 보내고
  2. 나머지 내용은 준비되는 대로 조금씩 보냄 (더 빠름)

쉽게 말하면, 기존 SSR은 "식당에서 모든 요리가 완성될 때까지 기다렸다가 한번에 서빙"하는 것이고, 새로운 방식은 "준비된 메뉴부터 먼저 서빙하고, 나머지는 완성되는 대로 가져다주는" 것과 비슷합니다.

React 서버 컴포넌트 (RSC)

• 목적: 번들 사이즈 최적화 및 서버 리소스 직접 접근
• 동작 방식:
  • 특정 컴포넌트를 서버에서만 실행되도록 지정
  • 서버에서 렌더링된 결과만 클라이언트로 전송
  • JS 번들에 서버 컴포넌트 코드는 미포함

두 기술의 상호보완적 관계

SSR과 서버 컴포넌트는 서로를 대체하는 기술이 아닌, 보완하는 기술입니다:

1. 역할 분담
   • SSR: 초기 페이지 로드 시 전체 HTML 생성
   • 서버 컴포넌트: 특정 컴포넌트들의 서버 실행 및 번들 크기 최적화

3. 프레임워크들의 서버 컴포넌트 구현

Next.js의 접근

Next.js는 자체적인 서버 컴포넌트 구현을 통해 React의 실험적 기능을 안정적으로 제공합니다.

1. React 코어 팀과 Next.js 팀의 협력
   • React 코어 팀의 주요 멤버들(Joe Savona, Sebastian Markbåge 등)이 Vercel(Next.js)에 합류
   • 이를 통해 React의 실험적 기능을 Next.js에서 먼저 안정적으로 구현 가능
2. 서버 컴포넌트의 발전 과정
   • 2020년: React 팀이 서버 컴포넌트 개념 첫 발표
   • React 18: 서버 컴포넌트 기초 인프라 포함, but 완전한 구현은 아님
   • Next.js 13: App Router와 함께 서버 컴포넌트 전면 도입

기술적 구현 방식

React의 Server Components에 대한 공식문서를 보면,

문서에서는 Server Components 구현에 대해 다음과 같이 언급하고 있습니다:

"To support React Server Components as a bundler or framework, we recommend pinning to a specific React version, or using the Canary release. We will continue working with bundlers and frameworks to stabilize the APIs used to implement React Server Components in the future."

이는 Server Components 구현을 위한 번들러 API가 아직 완전히 안정화되지 않았음을 시사합니다.

Next.js는 다음과 같은 방식으로 서버 컴포넌트를 구현했습니다:

// next.config.js
{
  webpack: (config, { isServer }) => {
    if (isServer) {
      // 서버 컴포넌트 처리
      config.plugins.push(new webpack.DefinePlugin({
        // marked, sanitize-html 같은 서버 전용 라이브러리들이
        // 클라이언트 번들에 포함되지 않도록 처리
        'process.env.SERVER_ONLY': JSON.stringify(true)
      }));
      
      config.module.rules.push({
        test: /\.(js|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-react'],
            plugins: [
              // async 컴포넌트 지원을 위한 변환
              '@babel/plugin-syntax-top-level-await',
              // Server Component의 import 구문 처리
              ['@babel/plugin-transform-modules-commonjs', {
                importInterop: 'node'
              }]
            ]
          }
        }
      });
    } else {
      // 클라이언트 컴포넌트 처리
      config.module.rules.push({
        test: /\.(js|jsx|ts|tsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-react'],
            plugins: [
              // "use client" 지시어가 있는 파일만 클라이언트 번들에 포함
              ['./plugins/client-directive', {}],
              // Server Component의 출력을 클라이언트에서 hydrate하기 위한 변환
              ['./plugins/server-reference', {}]
            ]
          }
        }
      });
    }
    return config;
  }
}

// Server Component 렌더링 함수
async function renderServerComponent(Component, props) {
  // 문서에 언급된 것처럼 build time 또는 request time에 실행 가능
  const stream = await ReactServerDOM.renderToReadableStream(
    <Component {...props} />,
    // 클라이언트 컴포넌트의 번들 정보를 담은 매핑
    webpackMap
  );
  
  // React의 Flight 포맷으로 직렬화
  return encodeRSCPayload(stream);
}

이 구현은 공식 문서의 다음 개념들을 반영합니다:

1. "Server Components are a new type of Component that renders ahead of time, before bundling, in an environment separate from your client app or SSR server."
   • webpack 설정에서 isServer 플래그로 환경을 분리
2. "Server Components can run once at build time on your CI server, or they can be run for each request using a web server."
   • renderServerComponent 함수가 이 두 가지 케이스를 모두 지원
3. "Async Components are a new feature of Server Components that allow you to await in render."
   • 서버 측 babel 설정에 @babel/plugin-syntax-top-level-await 포함

핵심 구현 요소

1. RSC 포맷
   • 서버 컴포넌트의 렌더링 결과를 특별한 포맷으로 직렬화
   • JSON이 아닌 특별한 바이너리 형식 사용
   • React Flight 아키텍처 활용
2. 번들링 최적화
   • 서버 전용 코드를 클라이언트 번들에서 제외
   • 클라이언트 컴포넌트만 선택적으로 번들링
3. 스트리밍 지원
   • React Suspense와 통합
   • 점진적인 페이지 로딩 구현

이해를 위해 기본적인 틀에 맞춰 간소화해 구현해 봤습니다!
혹시 틀린 부분이 있다면 편하게 댓글 주시면 감사하겠습니다!

Remix의 접근

Remix는 라우터 기반의 서버 중심 아키텍처를 채택하여 유사한 이점을 제공합니다.

// Remix의 서버 사이드 로직 예시
export async function loader({ request }) {
  const data = await getProducts();
  return json(data);
}

export default function Products() {
  const products = useLoaderData();
  return (
    <div>
      <h1>Products</h1>
      <ProductList products={products} />
    </div>
  );
}

4. Next.js 앱 라우터와 서버 컴포넌트의 관계

Next.js의 앱 라우터는 서버 컴포넌트를 기본값으로 채택했습니다.  매우 중요한 아키텍처적 결정이죠?!

기본 구조

// app/layout.jsx (서버 컴포넌트)
export default function RootLayout({ children }) {
  return (
    <html>
      <body>{children}</body>
    </html>
  );
}

// app/page.jsx (서버 컴포넌트)
async function Home() {
  const data = await getData(); // 서버에서 직접 데이터 fetch
  
  return (
    <main>
      <h1>Welcome</h1>
      <ClientComponent data={data} />
    </main>
  );
}

// components/client-component.jsx
'use client';

function ClientComponent({ data }) {
  // 클라이언트 사이드 인터랙션이 필요한 컴포넌트
  return <div>{/* 인터랙티브 UI */}</div>;
}

주요 특징

자동 코드 분할

// app/products/page.jsx
import { ProductList } from './components/product-list';

async function ProductsPage() {
  const products = await fetchProducts(); // 서버에서만 실행
  return <ProductList products={products} />;
}

// 이 컴포넌트와 관련된 서버 로직은 클라이언트 번들에 포함되지 않음

스트리밍과 Suspense 통합

// app/dashboard/page.jsx
import { Suspense } from 'react';

export default function Dashboard() {
  return (
    <div>
      <Suspense fallback={<LoadingUI />}>
        <SlowComponent />
      </Suspense>
    </div>
  );
}

마치며

현재 제가 진행 중인 프로젝트에서는 React 18.2.0을 사용하고 있어 서버 컴포넌트를 직접 사용하기는 어려운 상황입니다.

하지만 고객 피드백을 받은 후 Next.js로의 마이그레이션을 고려하고 있으며, 서버 컴포넌트의 이점을 자연스럽게 활용할 수 있는 좋은 기회가 될 것 같습니다.

프로젝트가 커지며, 번들 사이즈 최적화와 서버 리소스 활용 측면에서 큰 이점을 제공할 것으로 기대됩니다!

프로젝트에 도입될 무한 스크롤을 개발 중인 상황입니다.
개발을 진행하던 중 데이터가 무수히 많아질 경우 문제가 발생하진 않을까라는 생각에 무한 스크롤에 대한 최적화를 고민하게 되었습니다!
여러 최적화 중 하나는 버츄얼 스크롤에 대해 파트를 나눠 기록해두려 해요!

버츄얼 스크롤 이란?

버츄얼 스크롤(Virtual Scroll)은 대량의 데이터를 효율적으로 처리하기 위한 기술로, 사용자가 실제로 보고 있는 항목만 렌더링하여 성능을 개선합니다.

특히, 리스트나 그리드 형식의 데이터를 다룰 때 유용하게 사용됩니다.

이번 블로그에서는 버츄얼 스크롤을 사용해야 할 상황과, 실제 상용 라이브러리에서의 구현 방식을 살펴보겠습니다.

상용 라이브러리에 대한 설명은 별도의 글로 분리하였습니다!

해당 글에선 버추얼 스크롤을 직접 구현하기 전에 도입을 위해 찾아본 이미 상용화된 라이브러리에 대해 작성해 보겠습니다!

인기 라이브러리 개요

검토해본 버츄얼 스크롤을 지원하는 라이브러리로는 react-window, react-virtualized, react-virtuoso가 있습니다.

각 라이브러리는 고유한 접근 방식을 통해 버츄얼 스크롤을 구현하고 있으며, 다양한 사용 사례와 성능 요구사항에 맞추어 설계되었습니다.

이 중에서 React Virtualized는 가벼워진 버전인 React Window가 가장 많이 사용되며, React Virtuoso는 비교적 최근에 출시되어 사용량이 적지만 점점 인기를 끌고 있는 라이브러리입니다. React Virtuoso는 React Window에는 없는 기능들을 지원하여 가볍고 간단하면서도 다양한 요구에 대응할 수 있습니다. 이들 라이브러리는 가상 스크롤을 통해 스크롤을 내릴 때 데이터를 끊김 없이 보여줄 수 있는 windowing 처리를 지원합니다.

Windowing

Windowing은 현재 화면에 필요한 데이터만 표시하는 방법입니다. 긴 리스트의 경우 모든 데이터를 한 번에 렌더링하면 성능이 저하되고 렉이 발생할 수 있기 때문에, windowing 기술을 통해 효율적으로 데이터를 처리할 수 있습니다.

엘리님의 드림 코딩 Express 강의의 Rate Limit 관련 알고리즘을 학습하며 알게 됐던 개념인데 다시 보니 괜히 반갑네요! ㅎㅎ

스크롤 위치

• React Virtualized는 사용자가 스크롤한 위치를 기억하는 기능이 있어 페이지를 새로고침해도 그 위치에서 다시 시작할 수 있습니다.
• React Window는 스크롤 위치 저장 기능이 없어, 새로고침 후 최상단 항목으로 돌아가는 불편함이 있을 수 있습니다. 예를 들어, 1000개의 리스트 항목 중 700번째 항목을 보고 있다가 새로고침하면 최상단으로 이동합니다.
• 클라이언트 사이드 라우팅으로 인해 페이지 간 이동 시 상태가 유지되지만, URL이 변경되면 스크롤 위치가 초기화되어 페이지가 언마운트되고 새로운 컴포넌트가 마운트되기 때문에 초기 상태로 돌아갑니다.
• 언마운트 시 API 요청이 다시 발생할 수 있으며, Context API, Redux, React Query 등의 상태 관리 방법을 사용하여 불필요한 API 요청을 방지할 수 있습니다.

높이 계산 (정적, 동적)

• React Window는 정적인 높이를 지원하므로 리스트 항목의 높이가 일정해야 사용 가능합니다.
• React Virtualized는 동적인 높이를 지원하여 리스트 항목의 내용에 따라 높이가 달라져도 자동으로 계산할 수 있습니다. 이를 위해 CellMeasurer 컴포넌트를 사용할 수 있으며, 이 컴포넌트는 새로운 콘텐츠가 나타날 때 높이를 자동으로 재계산합니다.
• CellMeasurer와 함께 CellMeasurerCache를 사용하면 높이를 캐시하여 성능을 향상시킬 수 있습니다.

React Window

• 목적: 많은 데이터 리스트와 표 형식 데이터를 효율적으로 렌더링하여 뷰포트에 보이는 항목만 렌더링합니다.
• 주요 기능:
  • React Window는 기본적으로 정적인 높이를 가진 리스트와 그리드만 제공합니다. 필요한 최소한의 기능을 제공하여 경량화된 라이브러리입니다.
  • DOM 노드 수를 최소화하여 렌더링 시간과 메모리 사용량을 줄입니다.
  • 초보자를 위해 설계된 간단한 API로 성능에 중점을 둡니다.
  • react-window-infinite-loader와 같은 외부 패키지를 사용하여 데이터의 지연 로딩을 지원합니다.
• 사용법: 최소한의 설정으로 쉽게 사용할 수 있으며, 사용자 정의 속성과 이벤트 핸들러 또한 사용 가능합니다.

React Virtualized

• 목적: React Window와 유사하지만 더 복잡한 사용 사례를 위한 폭넓은 기능을 제공합니다.
• 주요 기능:
  • React Virtualized는 가상화된 그리드, 필터링, 정렬, 드래그 앤 드롭 등 다양한 기능을 제공합니다.
    • 가상화된 그리드는 동적인 높이 계산을 통해 사용자에게 보기 좋은 형태로 데이터가 배치됩니다.
    • 필터링 기능은 특정 조건에 맞는 항목만 표시할 수 있습니다.
    • 정렬 기능을 통해 사용자가 원하는 기준으로 리스트를 정렬할 수 있습니다.
    • 드래그 앤 드롭 기능을 통해 리스트 항목의 순서를 쉽게 변경할 수 있습니다.
    • 일부 스타일에 CSS가 필요하며, 번들 크기를 줄이기 위해 특정 구성 요소만 임포트할 수 있습니다.
    • 최적화를 위해 shallowCompare를 사용하여 props나 state가 변경되지 않으면 다시 렌더링하지 않습니다.
• 사용법: 복잡한 API 때문에 설정이 더 복잡할 수 있으며, react-window나 react-virtuoso와 비교해 애플리케이션의 번들 크기를 증가시킬 수 있습니다.
  
  

React Virtuoso

• 목적: 가변 크기 항목을 자동으로 처리하며, 다양한 기능을 제공하는 포괄적인 구성 요소 세트를 제공합니다.
• 주요 기능:
  • 수동 크기 조정 없이 가변 크기 항목을 자동으로 처리합니다.
  • 채팅 메시지 리스트
  • 스티키 헤더가 있는 그룹화된 항목
    • 리스트의 항목을 카테고리별로 그룹화 한다는 의미입니다!(제가 헷갈렸던 부분이라 풀어 적을게요!) 예를 들어, 제품 리스트가 "과일"이나 "채소"와 같은 카테고리로 나뉘어 있을 수 있습니다. 각 그룹에는 상단에 고정된 헤더가 있어 사용자가 리스트를 스크롤할 때 현재 어떤 그룹을 보고 있는지 쉽게 알 수 있게 해줍니다. 이 스티키 헤더 기능은 사용자에게 더 나은 맥락을 제공하여 사용 경험을 향상시킵니다.
  • 무한 스크롤 등을 지원합니다.
  • CSS 클래스 속성을 통해 동일한 크기의 항목을 여러 열로 표시할 수 있습니다.
• 사용법: 복잡한 리스트 뷰 구현을 단순화하여 직관적인 API로 개발자에게 사용하기 쉽게 설계되었습니다.

요약 및 마무리

• 성능: 세 라이브러리 모두 DOM 노드를 줄이고 렌더링을 최적화하여 성능을 향상시키는 데 중점을 둡니다.
• 복잡성: React Window가 가장 간단하고 경량이며, React Virtualized는 더 많은 기능을 제공하지만 복잡성이 증가합니다. React Virtuoso는 고급 기능과 사용 편의성의 균형이 좋습니다.
• 사용자 정의: 각 라이브러리는 사용자가 필요에 맞게 조정할 수 있는 다양한 옵션을 제공합니다. 특히 React Virtuoso와 React Virtualized는 스타일이나 레이아웃을 커스터마이즈하는 데 더 많은 유연성을 줍니다. 예를 들어, 사용자들은 자신만의 디자인 요구에 맞춰 항목의 크기, 색상, 배치 등을 자유롭게 변경할 수 있습니다. 
• React Window는 기본적인 리스트와 그리드, 정적인 높이를 지원하며, 필요 없는 기능들은 제거하여 가볍고 간단하게 사용할 수 있습니다. 작은 프로젝트에 적합하지만, 기능이 제한적입니다.
• React Virtualized는 많은 기능을 지원하며, 복잡한 UI/UX를 구축할 때 유용하지만, 설정이 복잡하고 파일 크기가 큰 단점이 있습니다.
• React Virtuoso는 경량화와 간편함을 추구하며, 최근 인기를 끌고 있는 라이브러리로, 필요한 기능이 많다면 다른 라이브러리와 함께 사용할 수도 있습니다.

이처럼 각 라이브러리는 각기 다른 특성과 장단점을 가지고 있으며, 프로젝트의 요구에 맞춰 선택하는 것이 중요합니다.