전문가를 위한 리액트 리뷰
나만 이해하면 돼서, 대충 쓰지만 읽는 사람도 이해했으면 하는 마음도 담아서 작성한다. 다만, 리뷰이면서 면접에 도움이 되었으면 하는 생각도 있기때문에 길어질 예정이니 목차 보고 궁금한 부분만 따라 가시길..
목차
1-입문자를 위한 지식
펼치기/접기
#### 1.1 리액트는 왜 필요한가요? 업데이트 때문이다. 이전에는 정적인 페이지가 많았다. 대규모 사이트들이 나오면서 즉각적인 느낌을 주길 바랐다. 그러나 아래와 같은 이유로 대규모 수행이 어려웠다. 웹 초창기에는 성능 : 브라우저가 페이지 레이아웃을 다시 계산하고(리플로우) 그리는 작업을 수행했다. 신뢰 : 한가지 상태를 여러 곳에서 추적했어야했다. 보안 : xss나 csrf 등을 방지하기 위해 import되는 것들을 모두 소독해야했다. --- #### 1.2 리액트 이전의 세계 - 클릭 -> 대기 -> 클릭 후 성공 또는 실패 - 브라우저에서 엘리먼트 탐색api를 사용해 버튼을 탐색 - 버튼에 이벤트 리스너를 추가해 클릭 이벤트를 추적 - 이벤트에 반응하여 상태를 업데이트 - 페이제에서 벗어날때 이벤트 리스너 제거 모든상태 정리 _오류가능성_ addForm 이나 submit같은 속서은 다른 클라이언트가 손쉽게 접근해 변형할수 있고, 이벤트 리스너도 문제가 생긴다.(이벤트는 언제 정리해줘야하고, 누적이 되진않는지 등..) _예측이 불가_ 자바스크립트와 HTML의 상호 의존성 때문에 다뤄야할 요소가 양쪽에 발생할수 있다. 그렇게 되면 어느쪽도 신뢰하기 어렵다. _비효율적_ dom의 변형은 계산 비용이 많이든다. ###### 제이쿼리 - 크기가 크며 로딩시간이 길다. - 최신 브라우저와의 중복된 기능의 API들까지 다 불러와야한다. - 성능을 저하시킨다. js나 블라우저가 제공하는 메서드가 더 효율적이다. | 프레임워크 | 장점 | 단점 | | ----------- | --------------------------------------------------------------- | -------------------------------------------------------------- | | Backbone.js | - 간단한 구조- 가벼움
- 빠른 학습곡선
- 커스터마이즈 쉬움 | - 큰 프로젝트에서 구조적 한계
- 뷰와 데이터 바인딩 약함
- Boilerplate 많음 | | Knockout.js | - MVVM 구조
- 양방향 데이터 바인딩 편리
- 학습 난이도 낮음 | - 대형 앱에 비효율적
- 컴포넌트 구조 부족
- 트렌드에서 벗어남 | | AngularJS | - 강력한 데이터 바인딩
- DI(의존성 주입) 지원
- SPA 개발 친화 | - 러닝 커브 높음
- 복잡한 구조
- 성능 이슈(1.x 기준) | | React | - 단방향 데이터 흐름
- 컴포넌트 기반
- Virtual DOM 통한 성능
- 커뮤니티 활발, 생태계 풍부 | - 상태 관리 추가 도구 필요
- JSX 학습 곡선
- 빠른 변화로 기존 코드 유지 어려움 | 이러한 단점들을 리액트는 어떻게 이겨냈을까? --- #### 1.3 리액트 등장 ##### 리액트의 핵심가치 - **선언형 코드** 하고싶은것을 선언하면 리액트가 알아서해준다. 어떻게는 생각안해도 된다. - **컴포넌트 기반** 구조로 앱의 재사용성과 유지보수가 크게 향상됨 - **단방향 데이터 흐름**은 복잡한 UI 상태 관리에 강점 - **Virtual DOM**으로 DOM 업데이트 성능과 효율 최적화 (재조정) - **생태계 확장**: Redux, Next.js 등 연동 도구와 커뮤니티 지원 - **값의 불변성**: 데이터(특히 state나 props)를 직접 변경하지 않고, 새로운 값으로 대체하는 원칙 > Backbone, Knockout, Angular 등은 각각 모바일, 대형, 복잡도에 따라 특화되고, 장점이 있었으나, React는 단순함과 유연성, 확장성과 생태계로 더 광범위하게 채택됨. --- ## 플럭스(Flux) 아키텍처란? 플럭스는 **리액트의 상태 관리 패턴**으로, 데이터의 흐름을 **단방향(one-way)** 으로 제어합니다. 주요 구성요소는 **Action → Dispatcher → Store → View(UI)** 순서로 데이터를 전달합니다. ### 구조 설명 1. **Action**: 사용자의 입력이나 이벤트 등으로 어떤 일이 일어나야 할지 알리는 메시지(객체). 2. **Dispatcher**: 모든 액션을 받아 각 스토어에 전달하는 역할(중앙 허브). 3. **Store**: 앱의 상태(state)와 로직을 관리. 상태가 변경되면 뷰에 알림. 4. **View(UI)**: 스토어로부터 상태를 받아 화면에 렌더링. 필요시 액션을 발동. --- ## 플럭스 장점과 단점 | 장점 | 단점 | | ------------------------------- | --------------------------------- | | 데이터 흐름이 단순하고 명확함 | Boilerplate 코드가 다소 많음 | | 상태 관리가 예측 가능함 | 기본만으로는 대규모 앱에 비효율적 | | 디버깅과 테스트가 쉬움 | 공식 구현이 없어 직접 구현해야 함 | | 컴포넌트 간 데이터 전달 용이 | 구현이 복잡하게 느껴질 수 있음 | --- ## Flux vs MVC vs MVVM | 패턴 | 데이터 흐름 | 주요 구성 요소 | 특징 | | ------ | -------------------- | ----------------------------------- | ------------------------------------------------------- | | MVC | 양방향 | Model, View, Controller | View와 Model이 직접 소통
데이터 흐름이 여러 방향
웹/초기 GUI에 주로 사용 | | MVVM | 양방향(주로) | Model, View, ViewModel | View와 ViewModel이 바인딩
UI와 로직 분리
Microsoft 계열에서 많이 사용 | | **Flux** | **단방향(One-way)** | Action, Dispatcher, Store, View | **데이터가 한 방향으로만 흐름**
액션→디스패처→스토어→뷰
상태 변경이 예측 가능
React와 함께 널리 쓰임 | --- ### 쉽게 설명하면 - **MVC/MVVM**: View와 상태(Model)가 서로 직접 주고받으며 바뀌는 구조. 복잡한 앱에선 예기치 않은 버그가 발생하기 쉬움. - **Flux**: 상태 변화가 오직 "액션"을 통해서만 일어나고, 데이터가 한쪽 방향으로만 흐름. 어디서 변화가 일어났는지 추적이 쉬워 대규모 앱에서 유리함.
2-JSX
펼치기/접기
#### 2.1 자바스크립트 XML? JSX는 자바스크립트 코드 안에서 XML(HTML)처럼 태그를 쓸 수 있게 해주는 문법입니다. --- #### 2.2 JSX의 장점 - **향상된 보안** XSS(스크립트 삽입) 공격을 방지하기 위해 JSX는 기본적으로 데이터를 이스케이프 처리한다. 예를 들어 태그 <> 는 < , > 이런식으로. - **강력한 타이핑** 타입스크립트와 함께 사용하면 컴파일 타임에 타입 오류를 잡을 수 있어 코드의 안정성이 높아집니다. 타입스크립트가 없어도 JSDoc스타일의 주석을 사용하거나 propTypes를 사용해 타입 안정성을 향상시킨다. - **컴포넌트 기반** UI를 작은 단위의 컴포넌트로 나눠서 재사용성과 유지보수가 뛰어납니다. - **광범위한 사용** React 생태계에서 표준처럼 사용되며, 많은 개발자와 자료가 존재해 학습과 협업이 쉽습니다. --- #### 2.3 JSX의 약점 - **학습곡선 가중** 자바스크립트와 HTML이 섞여 있어 처음 접하는 사람에게는 익숙해지기까지 시간이 걸릴 수 있습니다. - **전용 도구 필요** 브라우저가 JSX를 바로 이해하지 못하므로 Babel 등 트랜스파일러와 빌드 도구가 필수입니다. - **관심사 혼합** UI와 로직이 한 파일에 섞여 있어, 전통적인 관심사 분리(SOC) 원칙에 어긋난다는 비판이 있습니다. - **자바스크립트 호환성 부족** JSX는 자바스크립트의 모든 문법을 그대로 지원하지 않으며, 일부 문법은 사용할 수 없습니다. --- #### 2.4 내부 동작 JSX는 브라우저가 직접 이해하지 못하므로, 아래와 같은 과정을 거쳐 동작합니다. | 단계 | 설명 | | ------------ | -------------------------------------------------------------------- | | 1. 작성 | 개발자가 JSX 문법으로 코드를 작성합니다. | | 2. 변환 | Babel 같은 트랜스파일러가 JSX를 `React.createElement` 함수로 변환합니다. | | 3. 객체 생성 | 변환된 코드는 자바스크립트 객체(React Element)를 만듭니다. | | 4. 렌더링 | React가 이 객체를 읽어 가상 DOM(Virtual DOM)을 만듭니다. | | 5. 비교 | 변경 전 가상 DOM과 비교(Diff)하여 실제 DOM에 필요한 부분만 업데이트합니다. | **예시** JSX 코드: ```jsxHello, world!
``` 변환 결과: ```js React.createElement('h1', null, 'Hello, world!') ``` 이렇게 변환된 객체를 바탕으로 React가 효율적으로 화면을 그려줍니다. --- #### 2.5 JSX 프라그마 JSX 프라그마는 "JSX를 어떤 함수로 변환할지"를 지정하는 설정입니다. 기본적으로는 `React.createElement`로 변환되지만, 프레임워크나 라이브러리에 따라 다르게 지정할 수 있습니다. | 프라그마 예시 | 변환 결과 예시 | | --------------------- | ----------------------------------- | | (기본) React | React.createElement | | /* @jsx h */ (Preact) | h | **사용 예시** ```jsx /* @jsx h */Hi
``` → `h('h1', null, 'Hi')`로 변환 이렇게 프라그마를 바꾸면, React가 아닌 다른 라이브러리에서도 JSX를 활용할 수 있습니다. --- #### 2.6 표현식 JSX 내부에서는 중괄호 `{}`를 사용해 자바스크립트 표현식을 직접 쓸 수 있습니다. | 사용 예시 | 설명 | | ------------------------ | ------------------------------------ | | `{user.name}
` | 변수, 속성 등 값 출력 | | `{count + 1}
` | 연산 결과 출력 | | `{isLogin ? "O" : "X"}
` | 삼항 연산자 등 조건부 렌더링 | | `{list.map(item => 