[기술면접] React 부분 4

<목차>

10. flux 아키텍처
11. 리액트의 Strick모드
12. SPA

10. flux 아키텍처

• 페이스북에서 React애플리케이션을 더 효율적으로 상태를 관리하기 위해 제안한 애플리케이션 아키텍처 패턴
• 애플리케이션의 데이터 흐름을 단방향으로 제어

핵심 개념

1. Action(행동)

• 상태를 변경하기 위해 발생하는 이벤트
• 사용자가 버튼을 클릭하거나 데이터를 서버에서 가져오는 동작
• 단순한 객체 형식으로 정의

const action = {
  type: 'ADD_ITEM',
  payload: { id: 1, name: 'New Item' }
};

2. Dispatcher(디스패처)

• 중앙 허브 역할, 액션을 스토어에 전달
• 모든 액션은 Dispatcher를 통해 스토어로 전달

dispatcher.dispatch(action);

3. Store(스토어)

• 애플리케이션의 상태와 상태 변경 로직을 저장하는 곳.
• 여러 컴포넌트가 스토어를 구독하여 데이터 변경을 감지할 수 있다.
• 스토어는 액션에 따라 상태를 업데이트

const store = {
  state: { items: [] },
  update(action) {
    if (action.type === 'ADD_ITEM') {
      this.state.items.push(action.payload);
    }
  }
};

4. View(뷰)

• React 컴포넌트와 같이 UI를 담당하는 계층
• 스토어의 상태를 읽고, 상태가 변경되면 UI를 업데이트

function render() {
  console.log(store.state.items);
}

Flux의 데이터 흐름

• 단방향 데이터 흐름

1. 사용자가 액션을 트리거

• 사용자가 어떤 동작을 수행하면(버튼 클릭, 입력 등), 해당 동작을 나타내는 Action이 생성

2. Dispatcher가 액션을 스토어로 전달

• 생성된 액션은 Dispatcher를 통해 스토어로 전달

3. 스토어에서 상태를 업데이트

• 스토어는 액션의 종류를 확인하고, 상태를 변경

4. 뷰(View)가 업데이트

• 상태가 변경되면 뷰가 이를 감지하고 다시 렌더링

Flux를 사용하는 이유

1. 단방향 데이터 흐름

• 데이터가 예측 가능한 방향으로 흐르기 때문에 디버깅과 유지보수가 쉬워짐

2. 상태의 중앙 집중 관리

• 상태가 한 곳(스토어)에서 관리되므로 애플리케이션의 동작이 일관성 있게 유지

3. 컴포넌트 간 데이터 공유

• 여러 컴포넌트가 동일한 스토어를 구독하여 상태를 공유

4. 모듈과 확장성

• Flux의 각 요소는 독립적으로 설계되므로 애플리케이션을 확장하거나 새로운 기능을 추가하기 쉬움

Flux와 Redux의 관계

• Redux는 Flux 아키텍처를 기반으로 한 상태 관리 라이브러리

• Redux는 Flux에서 주요 변경점 도입

  1. Dispatcher제거 : Redux에서는 디스패처를 제거하고 단일 스토어를 중심으로 상태 관리
  2. 불변성 보장: Redux는 상태 변경없이 새로운 상태 객체를 반환
  3. 미들웨어 지원 : Redux는 미들웨어를 사용하여 액션의 비동기 처리를 간단히 구현

  Q. flux 아키텍처를 설명해주세요.

  11. 리액트의 Strict모드

• 애플리케이션의 잠재적인 문제를 감지, 개선된 React 기능을 더 안전하게 도임 할 수 있도록 돕는 개발 도구

• 개발 환경에서 Strict Mode를 적극적으로 사용 => 코드 폼질 향상

Strict Mode가 필요한 이유

• React 애플리케이션을 개발하면서 다음과 같은 문제가 발생할 가능성이 있다.
  1. 오래된 비권장 API를 사용하거나, 잘못된 코딩 패턴을 사용하는 경우
  2. 비동기 동작에서 예상치 못한 버그가 발생하는 경우
  3. React의 최신 기능을 도입할 때 기존 코드와 충돌하거나, 문제가 생기는 경우

Strict Mode가 제공하는 주요 기능

1. 안전하지 않은 생명주기 메서드 감지

• React의 클래스형 컴포넌트에서 사용되는 비권장 생명주기 메서드를 감지하고 경고를 출력
• 감지 대상 메서드
• componentWillMount
• componentWillReceiveProps
• componentWillUpdate

2. 의도하지 않은 부작용 감지

• React 18부터 두 번 렌더링, 의도하지 않은 부작용 때문
• useEffect, useState의 사용을 조기 발견할 수 있음

3. 비동기 동작 감지

• 비동기 작업의 오류를 출력

4. Deprecated API 감지

• 더이서 사용되지 않은 API를 감지 경고

Strict Mode의 한계
1. 운영 환경에서 동작하지 않음

• 개발모드에서만 동작, 프로덕션 빌드에서는 비활성화

2. 두번 렌더링에 따른 혼란

3. 수정이 되지 않음

• 문제를 감지하고 경고는 하지만 실제 문제는 해결되지 않음
• 개발자가 직접 문제를 수정해야함

Strict Mode가 권장되는 경우
1. 프로젝트 초기 단계에서 코드 품질을 유지하고 잠재적인 문제를 방지
2. React 최신 기능을 도입하거나 또는 코드가 최신 React 패턴과 호환되도혹 해야할 때
3. 협업 환경에서 코드 스타일과 안정성을 유지하고자 할 때

Strict Mode가 없어도 되는 경우
1. 레거시 프로젝트에서 대규모 리팩토링 없이 일부 기능만 React로 이식하는 경우
2. Strict Mode로 인해 발생하는 경고를 해결하기 어려운 경우

Q. 리액트의 Strict 모드는 왜 필요할까요?

12. SPA

• Single Page Application
• 단일 HTML 페이지로 구성
• 페이지 전환없이 사용자 인터페이스(UI)를 동적으로 업데이트하는 웹 애플리케이션 아키텍처

SPA와 MPA(Multi Page Application)의 차이점

특징	SPA	MPA
페이지 구조	단일 HTML 페이지	여러 개의 HTML 페이지
페이지 전환 방식	브라우저의 History API로 전환	서버 요청 후 새로운 페이지 로드
초기 로딩 시간	상대적으로 느림	상대적으로 빠름
SEO 지원	추가적인 설정 필요 (SSR/SSG)	기본적으로 지원
개발 복잡성	클라이언트 라우팅과 상태 관리 필요	상대적으로 간단
네트워크 요청	필요한 데이터만 가져옴	전체 페이지 요청

SPA의 주요 특징
1. 단일 HTML 페이지

• 애플리케이션 첫 로드시 하나의 HTML 페이지가 로드
• 이후 콘텐츠 변경은 브라우저에서 JavaScript를 이용해 동적으로 처리

2. 페이지 새로고임 없음

• 새로운 콘텐츠를 로드하기 위해 페이지를 다시 로드하지 않음
• 필요한 데이터만 서버에서 가져옴
• URL이 바뀌더라도 페이지 전체가 다시 로드되지 않음

3. 빠른 사용자 경험

• 서버에서 전체 HTML페이지를 다시 받아오지 않으므로 전환 속도가 빠름

4. 프론트엔드 중심

• 대부분의 로직(라우팅, 상태 관리 등)이 클라이언트 측에서 실행
• 리엑트등 프론트엔드 프레임워크와 잘 맞음

SPA 장단점
[장점]

1. 빠른 사용자 경험 : 한 번 로드된 후 페이지 새로고침 없이 전환
2. 부드러운 전환 : 페이지 전환 시 깜빡임 없이 콘텐츠가 업데이트
3. 효율적인 데이터 처리 : 서버에서 필요한 데이터 요청만 가져오기 때문에 효율적으로 네트워크 사용
4. 프론트엔드 중심 개발 : 사용자의 인터페이스와 애플리케이션 로직을 프론트엔드에서 관리 => 유지보수 용이
5. 재사용 가능성 : 동일한 SPA 애플리케이션을 모바일 앱(React Native)으로 쉽게 확장 가능

[단점]
1. SEO 문제 : 초기 로드시 HTML이 빈 상태로 제공되기 때문에 검색 엔진이 콘텐츠를 제대로 크로링 하지 못할 가능성 => 서버사이드렌더링이나 정적 사이트 생성 같은 기법 필요
2. 초기 로드 시간 증가 : 처음 로드시 모든 JavaScript와 CSS 파일을 다운로드 해야함 => 초기 로딩 속도 증가
3. 복잡성 증가 : 클라이언트에서 라우팅, 상태 관리, 비동기 데이터 처리 등을 모두 관리 => 개발 복잡성 증가
4. 자바스크립트 의존성 : 브라우저에 JavaScript가 비활성화되어 있으면 애플리케이션이 제대로 동작하지 않음
5. 보안 : 클라이언트 중심 애플리케이션은 XSS(Cross-Site Scripting) 같은 보안 취약점에 더 민감

**XSS란?

• Cross-Site Scripting
• 가장 일반적인 보안 취약점 중 하나
• 공격자가 악성스크립트(JavaScript)를 삽입하여 사용자 정보를 탈취하거나 악의적인 행동을 수행하도록 하는 공격
• 보통 애플리케이션이 사용자 입력을 적절히 검증하지 않고 HTML이나 JavaScript로 렌더링 할 때 발생

**XSS의 동작 원리
1. 공격자가 악성 스크립트를 포함한 데이터를 입력:

• 예를 들어, 검색창, 댓글란, URL 매개변수 등에 악성 코드를 삽입.

2. 웹 애플리케이션이 입력값을 적절히 검증하지 않고 출력:

• 입력값을 HTML이나 JavaScript로 처리하며 실행.

3. 다른 사용자가 악성 코드가 포함된 페이지를 열람:

• 브라우저가 악성 코드를 실행하면서 피해자가 의도하지 않은 동작 발생.

4. 피해자의 브라우저에서 민감한 정보가 노출:

• 예: 쿠키 탈취, 세션 하이재킹, 사용자 키 입력 감시 등.

Q. SPA에 대해 설명해주세요.