먼저 Redux는 상태를 중앙 집중화된 스토어에 저장하는 방식으로, 상태의 흐름이 명확하고 예측 가능합니다. 이 덕분에 상태를 쉽게 추적하고 관리할 수 있어요. 또한, 비동기 작업을 처리할 수 있는 미들웨어, 예를 들어 Thunk나 Saga를 지원해 복잡한 비즈니스 로직을 간편하게 구현할 수 있습니다. 그리고 Redux DevTools 같은 강력한 디버깅 도구를 통해 상태 변화를 쉽게 확인할 수 있다는 장점이 있습니다. 하지만, 설정이 복잡하고 보일러플레이트 코드가 많아 초기 구현에 시간이 걸린다는 단점이 있습니다.
반면에 useContext는 React의 내장 훅으로, 더 간단하게 상태를 관리할 수 있는 방법입니다. 작은 애플리케이션에서는 빠르고 직관적으로 상태를 공유할 수 있어서 매우 유용하죠. 하지만, 상태가 변경될 때마다 그 상태를 사용하는 모든 컴포넌트가 다시 렌더링되기 때문에 성능 저하의 우려가 있습니다. 또한, 상태가 복잡해지면 관리하기 힘들어질 수 있다는 한계도 있습니다.
결론적으로, Redux는 대규모 애플리케이션에 더 적합하고, useContext는 간단한 상태 관리에 더 유리하다고 할 수 있습니다. 상황에 맞게 적절한 도구를 선택하는 것이 중요합니다.
Redux
- 구조적 관리: 상태를 중앙 스토어에 저장, 예측 가능한 상태 관리.
- 미들웨어: 비동기 작업을 쉽게 처리할 수 있어 복잡한 로직에 유리.
- 디버깅 도구: Redux DevTools로 상태 변화를 쉽게 추적 가능.
- 보일러플레이트: 설정이 복잡하고 코드가 많아 초기 설정에 시간이 필요함.
useContext
- 간편함: React의 내장 훅으로 간단한 상태 공유 가능.
- 단순한 상태 관리: 작은 애플리케이션에 적합, 빠르게 구현 가능.
- 성능 문제: 상태 변경 시 모든 관련 컴포넌트가 리렌더링되어 성능 저하 우려.
- 복잡성 한계: 상태가 복잡해지면 관리가 어려워질 수 있음.
SSR(서버 사이드 렌더링) : 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식입니다.
장점
- SEO 최적화: 서버에서 HTML을 미리 생성하므로 검색 엔진 최적화에 유리합니다.
- 빠른 초기 로드: 사용자에게 처음 페이지를 빠르게 표시할 수 있습니다.
단점- 서버 부하: 모든 요청에 대해 서버가 렌더링을 해야 하므로 서버에 부담이 큽니다.
- 상호작용 지연: 클라이언트에서 추가적인 상호작용이 필요할 때, 페이지 로드가 느려질 수 있습니다.
CSR(클라이언트 사이드 렌더링) : 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.
장점
- 빠른 사용자 경험: 페이지 간 전환이 빠르고 부드럽습니다.
- 서버 부하 감소: 서버는 데이터만 제공하고, 렌더링은 클라이언트에서 처리합니다.
단점- SEO 문제: 초기 HTML이 비어 있어 검색 엔진 최적화에 불리할 수 있습니다.
- 느린 초기 로드: JavaScript가 로드되고 실행될 때까지 초기 화면이 늦게 나타날 수 있습니다.
Vercel은 프론트엔드 개발을 위한 클라우드 플랫폼으로, 특히 Next.js와 같은 React 프레임워크와 잘 통합됩니다.
Vercel의 큰 장점 중 하나는 GitHub와 쉽게 연동된다는 점이에요. GitHub에 코드를 올리면, Vercel이 자동으로 빌드하고 배포해 줍니다. 이 덕분에 개발자가 수동으로 배포할 필요 없이, 코드 변경이 있을 때마다 자동으로 업데이트됩니다.
또한, Vercel은 빠른 로딩 속도를 제공하는 글로벌 CDN을 사용하므로, 좀 더 나은 사용자 경험을 제공합니다. 그리고 Vercel은 개발자가 웹사이트를 쉽게 만들고, 빠르게 배포할 수 있도록 도와주는 플랫폼이에요.
프로젝트 규모가 작은 경우에는 useContext나 간단한 상태 관리로 충분하지만, 대규모 프로젝트에서는 Redux와 같은 구조화된 솔루션이 필요합니다. 상태가 복잡하거나 비동기 처리가 많을 경우, Redux를 사용하는 것이 적합합니다. 그러나 Redux의 초기 설정이 복잡하고 코드량이 많다는 단점을 보완하기 위해, Zustand와 같은 라이브러리를 사용합니다.
쓰로틀링과 디바운스는 주로 이벤트 핸들링에서 성능을 최적화하기 위한 기법입니다.
쓰로틀링은 특정 시간 간격마다 함수가 실행되도록 제한하는 방법입니다. 예를 들어, 사용자가 스크롤할 때 1초에 한 번만 함수가 호출되도록 설정할 수 있습니다. 이렇게 하면 성능 저하를 방지할 수 있습니다.
반면에 디바운스는 함수 호출을 연기해서, 일정 시간 동안 추가 호출이 없을 때만 함수를 실행하는 방식입니다. 예를 들어, 사용자가 입력을 멈춘 후 300ms가 지나야만 API 요청을 보내도록 설정할 수 있습니다. 이렇게 하면 불필요한 요청을 줄이고, 네트워크 비용을 절감할 수 있습니다.
이 두 가지 기법을 사용하면 웹 애플리케이션의 성능을 향상시키고, 사용자 경험을 개선할 수 있습니다.
useEffect는 React 훅으로, 컴포넌트가 렌더링된 후 특정 작업을 수행할 수 있게 해줍니다. 주로 데이터 fetching, 구독 설정, 타이머 설정 등 부수 효과를 관리하는 데 사용됩니다. 이 훅은 의존성 배열을 통해 어떤 값이 변경될 때만 특정 작업을 실행하도록 제어할 수 있습니다.
useEffect 특징
- 컴포넌트가 렌더링된 후 실행됩니다.
- 의존성 배열을 통해 실행 시점을 조절할 수 있습니다.
- 클린업 함수를 반환할 수 있어, 컴포넌트가 언마운트될 때 작업을 정리할 수 있습니다.
useCallback은 메모이제이션을 통해 함수를 기억해두는 훅입니다. 주로 자식 컴포넌트에 함수를 props로 전달할 때, 불필요한 렌더링을 방지하기 위해 사용됩니다. useCallback은 의존성 배열에 있는 값이 변경될 때만 새로운 함수를 반환합니다.
useCallback 특징- 함수를 메모이제이션하여 성능을 최적화합니다.
- 자식 컴포넌트에 props로 전달할 때 유용합니다.
- 의존성 배열을 통해 언제 함수를 새로 생성할지를 제어할 수 있습니다.
차이점
- useEffect는 부수 효과를 처리하는 데 사용되고, useCallback은 함수를 메모이제이션하는 데 사용됩니다.
- useEffect는 렌더링 후 실행되지만, useCallback은 렌더링 중에 함수를 기억합니다.
JavaScript는 단일 스레드 언어로, 한 번에 하나의 작업만 처리할 수 있습니다. 하지만 비동기 작업을 효율적으로 처리하기 위해 이벤트 루프라는 메커니즘을 사용합니다.
기본 구조
1. 콜 스택 (Call Stack): 현재 실행 중인 함수의 호출을 관리합니다. 함수가 호출되면 스택에 쌓이고, 실행이 끝나면 제거됩니다.
2. 힙 (Heap): 메모리 관리 공간으로, 객체와 변수를 저장합니다.
3. 이벤트 큐 (Event Queue): 비동기 작업의 결과나 이벤트가 발생했을 때 실행할 콜백 함수가 대기하는 큐입니다.
4.이벤트 루프 (Event Loop): 콜 스택이 비어 있을 때, 이벤트 큐에 대기 중인 콜백을 콜 스택으로 가져와 실행합니다.
작동 방식
- JavaScript 코드가 실행되면, 먼저 콜 스택에 쌓입니다.
- 비동기 작업이 발생하면, 해당 작업의 콜백은 이벤트 큐에 대기하게 됩니다.
- 콜 스택이 비어 있으면 이벤트 루프가 이벤트 큐에서 대기 중인 콜백을 가져와 실행합니다.