Context API

React의 Context는 컴포넌트 간에 데이터를 전달하는 메커니즘을 제공하는 React API입니다. 일반적으로 React 컴포넌트는 상위 컴포넌트로부터 데이터를 props로 전달받습니다. 그러나 컴포넌트 트리의 여러 단계를 거치는 경우, 중간 컴포넌트들이 해당 데이터를 모두 전달해야 하는 번거로움이 생길 수 있습니다. 이런 경우 Context를 사용하면 데이터를 중간 컴포넌트 없이도 효율적으로 전달할 수 있습니다.

Context를 사용하면, 상위 컴포넌트에서 생성한 데이터(또는 상태)를 모든 하위 컴포넌트에서 직접 접근할 수 있습니다. 이를 통해 컴포넌트 간의 데이터 흐름을 간소화하고, 데이터가 필요한 곳에서 쉽게 사용할 수 있도록 합니다.

Context Provider

Context 데이터를 제공하는 컴포넌트입니다. Context Provider는 일반적으로 상위 컴포넌트에서 생성하며, createContext 함수를 사용하여 생성할 수 있습니다. 이 컴포넌트는 자식 컴포넌트에게 데이터를 제공하기 위해 value prop을 사용하여 데이터를 전달합니다.

Context Consumer

Context 데이터를 필요로 하는 하위 컴포넌트에서 사용됩니다. useContext 훅을 사용하거나 Consumer 컴포넌트를 이용하여 Context 데이터를 소비(consume)합니다. 이를 통해 해당 컴포넌트에서 Context 데이터를 직접 사용할 수 있습니다.

Context

Context 객체 자체입니다. 이 객체를 통해 Provider와 Consumer를 만들고, Context 데이터를 생성하고 공유합니다.

createContext() 메소드를 통해 먼저 context 객체를 만들고, 부모 컴포넌트에서 해당 객체의 Provider 컴포넌트를 이용해서 value props를 통해 데이터를 전달합니다.
그리고 자식 컴포넌트에서 Consumer 컴포넌트 또는 useContext 훅을 이용해서 데이터를 전달 받아 사용합니다.

// Context 생성
const MyContext = React.createContext();

// Context Provider
const ParentComponent = () => {
  const data = "Hello from Context!";

  return (
    <MyContext.Provider value={data}>
      <ChildComponent />
    </MyContext.Provider>
  );
};

// Context Consumer
const ChildComponent = () => {
  const data = React.useContext(MyContext);

  return <div>{data}</div>; // 출력: Hello from Context!
};

SPA(Single Page Application)

SPA(단일 페이지 애플리케이션)는 웹 애플리케이션의 일종으로, 하나의 HTML 페이지를 기반으로 동적으로 콘텐츠를 변경하며 사용자와 상호작용하는 웹 애플리케이션입니다. 기존의 전통적인 멀티 페이지 웹 애플리케이션과는 다른 접근 방식을 가지고 있습니다.

전통적인 멀티 페이지 웹 애플리케이션은 매 페이지 요청마다 새로운 HTML을 받아와 전체 페이지를 다시 렌더링하는 방식이었습니다. 이로 인해 페이지 간 전환 시 매번 서버로부터 새로운 페이지를 받아와야 하므로, 사용자 경험이 떨어질 수 있습니다. 또한, 서버와의 통신이 필요하기 때문에 새로운 페이지 로딩 시간도 증가하게 됩니다.

이와 달리, SPA는 초기에 한 번 페이지를 로딩한 후, 페이지 이동 시에 서버로부터 새로운 페이지를 받아오는 것이 아니라, 클라이언트 측에서 필요한 데이터만 받아와 페이지를 동적으로 갱신합니다. 이로 인해 페이지 간의 전환 속도가 빠르며, 사용자 경험을 향상시킬 수 있습니다.

1. 단일 페이지: SPA는 하나의 HTML 페이지로 구성되어 있습니다. 페이지 간 전환 시 새로운 페이지를 서버로부터 받아오는 것이 아니라, 동적으로 콘텐츠를 변경하여 사용자에게 보여줍니다.

2. 동적 업데이트: virtual dom을 이용해서 실제 dom의 조작 비용을 최소화하고 렌더링 성능을 향상시켜 줍니다. 페이지의 일부분만 동적으로 업데이트되므로, 사용자의 상호작용에 따라 필요한 부분만 새로 로딩합니다. 이는 서버로의 요청을 줄이고 애플리케이션의 반응성을 향상시킵니다.

3. 클라이언트 사이드 렌더링(CSR): 콘텐츠를 클라이언트 측에서 동적으로 렌더링하므로, 서버 측에서는 데이터만 제공하면 됩니다. 이로 인해 서버의 부담이 줄어들고, 서버와 클라이언트 간의 통신을 최소화할 수 있습니다.

4. 라우팅: SPA는 클라이언트 측에서 라우팅을 처리합니다. URL의 변경에 따라 필요한 컴포넌트를 동적으로 로딩하여 적절한 페이지를 보여줍니다.

5. 프론트엔드 프레임워크/라이브러리: 주로 React, Angular, Vue.js 등의 프론트엔드 프레임워크나 라이브러리와 함께 사용됩니다. 이러한 도구들은 SPA의 개발과 관리를 용이하게 해줍니다.

SPA의 장점은 좋은 사용자 경험과 빠른 페이지 간 이동 속도 등이 있지만, 초기 로딩 시 모든 자원을 받아와야 하므로 초기 로딩 속도가 느릴 수 있습니다. 또한, 브라우저의 뒤로 가기와 같은 기본적인 기능을 구현하기 위해서도 추가적인 처리가 필요할 수 있습니다. 이러한 단점들을 극복하기 위해 코드 스플리팅과 라우팅 처리에 주의하여 개발하는 것이 중요합니다.

Next.js

React 언어를 사용하여 만든 SPA(Single Page Application)와 SSR(Server-Side Rendering)이 가능한 Next.js 라이브러리를 사용한 프로젝트는 SPA이면서 SSR이 가능합니다.

React는 기본적으로 클라이언트 측에서 동작하는 라이브러리로, SPA를 구현하는데 사용됩니다. SPA는 페이지 간의 전환 시에 서버로부터 새로운 페이지를 받아오지 않고, 클라이언트 측에서 페이지를 동적으로 갱신하는 방식을 사용합니다. 이로 인해 사용자 경험이 향상되고, 페이지 간의 전환 속도가 빠릅니다.

Next.js는 React 기반의 프레임워크로서, 서버 측 렌더링(SSR)을 지원합니다. SSR은 SPA의 초기 로딩 속도를 개선하기 위해 서버 측에서 최초로 페이지를 렌더링하는 기술입니다. 따라서 Next.js를 사용하면 SPA처럼 클라이언트 측에서 동작하는 이점을 유지하면서도 SSR을 통해 초기 로딩 속도를 개선할 수 있습니다.

Next.js는 라우팅과 데이터 미리 불러오기 등 SSR을 간편하게 구현할 수 있는 기능을 제공합니다. 또한, 필요에 따라서는 클라이언트 측에서 SPA처럼 동작하도록 할 수도 있습니다. 따라서 Next.js로 만든 프로젝트는 SPA이면서 SSR이 가능한 장점을 동시에 가지고 있습니다.

예를 들어, Next.js를 사용하여 만든 프로젝트는 초기 로딩 시에 서버 측에서 페이지를 렌더링하여 사용자에게 보여줍니다(SSR). 그 후, 페이지 간 전환은 클라이언트 측에서 SPA처럼 동적으로 처리되며(CSR), 필요한 데이터는 미리 불러오거나 필요 시에 비동기로 불러올 수 있습니다. 이를 통해 최적화된 사용자 경험과 검색 엔진 최적화(SEO)를 동시에 얻을 수 있습니다.

react.js에 next.js가 있다면, vue.js에는 동일한 기능을 할 수 있도록 해주는 라이브러리 nuxt.js가 있습니다.

Hydration(하이드레이션)

Hydration은 서버 사이드 렌더링(SSR)을 통해 서버에서 최초로 렌더링된 HTML에 대해 클라이언트에서 이루어지는 과정입니다. 서버 사이드 렌더링은 웹 페이지의 초기 렌더링을 빠르게 하고, 검색 엔진 최적화(SEO)에 도움을 주는 장점이 있습니다. 하지만 초기 렌더링 이후에는 웹 애플리케이션이 클라이언트 사이드 라우팅을 통해 동적으로 페이지를 변경하고 업데이트해야 할 때가 있습니다.
서버 사이드 렌더링으로 생성된 HTML은 브라우저에 로드되면서 클라이언트 사이드 라이브러리(예: React)가 해당 HTML에 이벤트 핸들러 등을 붙이고 상호작용을 설정합니다. 이렇게 웹 애플리케이션은 초기 렌더링 이후에도 사용자와의 상호작용에 응답하면서, 변경된 부분만 업데이트하여 동적 렌더링을 가능하게 합니다. 이 과정을 Hydration이라고 합니다. 하이드레이션 덕분에 Next.js는 CSR의 동적 렌더링과 SSR의 최초 HTML 파일 렌더링의 강점을 둘 다 살릴 수 있습니다.

Svelte(스벨트)

Svelte는 컴파일러를 사용하여 빌드 시점에 코드를 변환하며, 이를 통해 런타임에 Virtual DOM을 사용하지 않고도 효율적인 돔 조작을 가능하게 합니다.

일반적인 SPA 라이브러리들은 Virtual DOM을 사용하여 상태가 변경될 때마다 가상 돔과 실제 돔을 비교하고 업데이트합니다. 이러한 과정은 메모리와 CPU 자원을 소비하며, 복잡한 UI나 상태가 많은 경우에는 성능 저하를 가져올 수 있습니다.

반면, Svelte는 컴파일러를 사용하여 컴포넌트 코드를 컴파일 시점에 JavaScript 코드로 변환합니다. 이렇게 변환된 코드는 실제 돔 조작 코드가 됩니다. Svelte 컴파일러는 컴포넌트 코드에서 상태 변경을 추적하고, 변경된 부분만 실제 돔에 반영하는 최적화된 코드를 생성합니다.

결과적으로 Svelte는 런타임에 Virtual DOM을 사용하지 않고, 컴파일 시점에 최적화된 실제 돔 조작 코드를 생성함으로써 메모리 사용량과 런타임 성능을 최적화합니다. 이는 Svelte를 더 가볍고 빠르게 만들어주는 주요한 특징 중 하나입니다.

Svelte의 접근 방식은 개발자가 코드를 작성할 때 더 직관적이고 간단하게 작성할 수 있게 해줍니다. 개발자는 가상 돔과 관련된 추가적인 세부 사항을 신경 쓰지 않고, 단순히 상태를 변경하고 컴포넌트를 정의하는 것에 집중할 수 있습니다. Svelte가 빌드 시점에서 최적화를 수행하기 때문에 높은 성능을 유지하면서도 코드 작성의 편의성을 제공합니다.

Svelte의 접근 방식은 개발자가 코드를 작성할 때 더 직관적이고 간단하게 작성할 수 있게 해줍니다. 개발자는 가상 돔과 관련된 추가적인 세부 사항을 신경 쓰지 않고, 단순히 상태를 변경하고 컴포넌트를 정의하는 것에 집중할 수 있습니다. Svelte가 빌드 시점에서 최적화를 수행하기 때문에 높은 성능을 유지하면서도 코드 작성의 편의성을 제공합니다.

스벨트와 기존 SPA 라이브러리의 차이

기존의 SPA 라이브러리들이 Virtual DOM을 도입한 이유는 성능 최적화와 상태 변경 추적의 용이성 때문입니다. Virtual DOM을 사용하면 상태가 변경될 때마다 이전 Virtual DOM과 새로운 Virtual DOM을 비교하여 변경된 부분만 돔에 반영하여 불필요한 돔 조작을 줄이고 성능을 향상시킬 수 있습니다. 또한, Virtual DOM은 라이브러리에서 상태 변경을 추적하고 UI를 업데이트하는 데에도 도움을 주므로 개발자가 더 쉽게 상태 관리를 할 수 있게 됩니다.

그러나 Svelte는 컴파일 시점에 코드를 변환하고, 상태 변경을 추적하여 빌드 시점에서 최적화된 돔 조작 코드를 생성합니다. 이렇게 생성된 코드는 런타임에 돔을 조작하며 동적 렌더링을 가능하게 합니다. Svelte는 컴파일러가 상태 변경을 감지하고 해당 상태에 의존하는 코드를 생성하므로, 런타임에 추가적인 비용 없이 최적화된 돔 조작을 할 수 있습니다.

따라서 Svelte는 Virtual DOM을 사용하지 않고도 성능을 최적화하고, 직접 돔을 조작하면서 동적 렌더링을 가능하게 하는 리액티브 시스템을 통해 이러한 기능을 구현합니다. 이는 개발자가 코드를 간결하게 작성하면서도 높은 성능을 유지할 수 있도록 도와줍니다.

Virtual DOM은 메모리 상에 가상의 돔 트리를 유지하고, 상태 변경이 발생할 때마다 이를 비교하여 업데이트하는 방식으로 동작합니다. 이는 돔 조작을 추상화하기 위해 사용되는 효과적인 방법이지만, 가상 돔을 유지하는 데에는 일정한 메모리와 계산 비용이 발생합니다. 따라서 복잡한 UI를 다룰 때나 큰 규모의 애플리케이션에서는 Virtual DOM을 사용하는 것이 동작 속도에 영향을 미칠 수 있습니다.

스벨트는 컴파일 시점에 최적화된 코드를 생성하고, 상태 변경을 추적하여 변경된 부분만을 업데이트하는 방식을 사용합니다. 이로 인해 불필요한 돔 조작을 최소화하고, Virtual DOM을 유지하는 데 필요한 리소스를 줄일 수 있습니다. 또한, 리액티브 시스템을 활용하여 상태 변경을 추적하는 과정도 Virtual DOM의 비교 과정보다 더 효율적으로 동작할 수 있습니다.

결국 스벨트는 컴파일 시점에 최적화되고 리액티브 시스템을 통해 상태 변경을 추적하여 필요한 부분만을 돔에 업데이트하여 성능을 향상시킵니다. 이러한 설계로 인해 스벨트는 리소스를 효율적으로 사용하면서도 빠른 렌더링과 업데이트를 제공합니다. 그렇기 때문에 스벨트는 일반적으로 Virtual DOM을 사용하는 라이브러리보다 더 가볍고 빠르게 동작할 수 있습니다.

JavaScript 정적 타입 검사 도구

1. 마이크로소프트 개발에서 개발한 TypeScript
2. 페이스북에서 개발한 Flow

위 라이브러리들을 이용하여 코드의 타입을 사전에 명시하고, 코드가 실행되기 전에 타입 에러를 찾아내는 것이 가능합니다. 따라서 런타임에 발생할 수 있는 많은 버그를 사전에 방지할 수 있습니다. 이를 통해 코드 가독성 및 유지보수성을 높일 수 있습니다.

react 상태 관리 도구

1. React-Query

React-Query는 서버 상태와 데이터를 관리하기 위한 라이브러리입니다. 주로 원격 API 호출과 데이터 캐싱을 쉽게 처리하며, 비동기 데이터를 쉽게 가져오고 조작할 수 있도록 설계되었습니다.

주요 특징:

• 데이터 Fetching: 서버에서 데이터를 가져오는 비동기 작업을 지원합니다. HTTP 요청과 GraphQL 쿼리를 손쉽게 처리할 수 있습니다.
• 캐싱: 가져온 데이터를 자동으로 캐싱하여, 같은 요청을 반복적으로 보낼 때 불필요한 네트워크 호출을 방지합니다.
• 리패칭과 리프레싱: 주기적으로 데이터를 새로 고치거나, 재요청하여 최신 데이터를 유지할 수 있습니다.
• 에러 핸들링: 비동기 작업 중 발생하는 오류를 처리하고, 오류 상태를 관리할 수 있습니다.

2. Recoil

Recoil은 페이스북에서 개발한 React 상태 관리 라이브러리입니다. React 컴포넌트 트리 내에서 상태를 전역적으로 관리하고 공유하는데 사용됩니다. 기본적으로 React의 컴포넌트 상태와 유사한 방식으로 상태를 정의하고 사용합니다.

주요 특징:

• 아톰(Atoms): 컴포넌트 간에 공유할 수 있는 상태 단위를 "아톰"이라고 합니다. Recoil은 이러한 아톰을 생성하고 정의하는 방식으로 상태를 관리합니다.
• 선택기(Selectors): 아톰을 기반으로 데이터를 변환하거나 연산하는 함수를 "선택기"라고 합니다. 선택기는 다른 선택기나 아톰과 의존성을 가질 수 있습니다.

3. Jotai

Jotai는 Recoil의 영향을 받아 개발된 간단하고 미니멀한 상태 관리 라이브러리입니다. Recoil과 유사한 아이디어와 패턴을 제공하지만, 더 경량화되어 있습니다.

주요 특징:

• 아톰과 컨텍스트: Jotai는 아톰과 컨텍스트 개념을 사용하여 전역 상태를 관리합니다. 컴포넌트 트리 내에서 이러한 상태를 손쉽게 공유할 수 있습니다.
• 리액트 훅 지원: Jotai는 React 훅을 통해 상태를 생성하고 조작할 수 있습니다.

4. Zustand

Zustand는 React를 위한 간단한 리액트 상태 관리 라이브러리입니다. 상태를 관리하기 위해 React의 useReducer 훅과 Context API를 기반으로 합니다.

주요 특징:

• useReducer 기반: 상태를 관리하는 데에 useReducer 훅과 함께 제공되는 dispatch 함수를 사용합니다.
• 컨텍스트 지원: 상태를 컨텍스트 API를 이용하여 컴포넌트 트리 내에서 공유할 수 있습니다.

각 라이브러리나 패턴은 프로젝트의 크기, 복잡도, 팀의 선호도에 따라 선택될 수 있습니다. React-Query는 주로 데이터 통신과 관련하여 사용되며, Recoil과 Jotai는 복잡한 상태 관리를 위해 사용되고, Zustand는 상대적으로 간단한 프로젝트나 상태 관리에 적합합니다.

Redux 또한 Recoil, Zustand와 마찬가지로 전역 상태 관리를 위한 라이브러리입니다. 공통적인 특징은 다음과 같습니다.

1. 상태 불변성 : 상태를 불변성을 유지하면서 업데이트하는 방식입니다. 이를 통해 상태 변경을 추적하고 안정적으로 상태를 공유 및 관리할 수 있습니다.
2. 컴포넌트 분리 : 컴포넌트 UI와 상태 관리 로직을 분리하여 유지보수성과 가독성을 높이고, 재사용성도 높아졌습니다.
3. Context API 기반 : Context 트리 내부에서 변수 및 상태를 자유롭게 공유하고 관리할 수 있습니다.

상태 불변성(Immutability)

프로그래밍에서 변경 불가능한(immutable) 데이터를 의미합니다. 즉, 데이터가 한 번 생성되면 그 값을 변경할 수 없는 것을 말합니다. 상태 불변성은 많은 언어와 라이브러리에서 중요하게 다루어지며, 특히 React, Redux 등과 같은 라이브러리에서 상태 관리를 위해 사용됩니다.

상태 불변성을 유지하는 것은 데이터의 변화를 추적하고 관리하는 데 매우 중요합니다. 여기에는 몇 가지 이점이 있습니다:

1. 예측 가능한 데이터 변경
상태 불변성을 유지하면 데이터의 변화를 추적하기 쉽습니다. 객체나 배열과 같은 복잡한 데이터 구조를 변경할 때, 이전 상태를 복제하고 변경한 새로운 상태를 반환하여 예측 가능한 방식으로 데이터를 업데이트할 수 있습니다.

2. 시간 여행 (Time Travel)
상태가 불변성을 유지하면 이전 상태를 기록해두어 시간 여행 디버깅과 같은 기능을 구현하는 데 도움이 됩니다. 시간 여행은 개발자가 과거의 애플리케이션 상태를 디버깅하고 검사할 수 있는 기능을 말합니다.

3. 성능 최적화
불변성을 유지하면 객체의 변경 여부를 감지하는 데에도 도움이 됩니다. 이는 React와 같은 UI 라이브러리에서 불필요한 렌더링을 방지하는 데 도움이 됩니다.

오늘의 CS 지식

접두어(prefix), 접미어(suffix)