- 리액트 컴포넌트의 render 함수만 사용해도 상당히 많은 애플리케이션을 만들 수 있음
- 하지만 자바스크립트는 callback의 연속이기 때문에 이런 부분을 처리해야할 요소가 필요하다.
- 컴포넌트가 마운트되거나 갱싱될 때 호출되는 일련의 메서드들
- 위 그림과 같은 구조로 되어 있음
- 크게 2가지의 생애주기 그룹으로 구성할 수 있다.
-
컴포넌트가 마운트되거나 언마운트되면 호출되는 메서드
-
마운트 되거나 언마운트 될 때 딱 한 번만 호출하는 메서드
-
보통 최초 상태를 설정하거나, API를 호출, 타이머 처리, 서드파티 라이브러리를 초기화하는 등의 작업에 사용
-
마운트란?
- 끼우다, 고정하다, 올라타다 등의 사전적 의미
- 리액트에서는 컴포넌트를 특정 영역에 끼워넣는 행위를 가리킨다.
- 예로 ReactDOM.render 함수를 통해서 DOM의 특정 영역에 리액트 컴포넌트를 끼워 넣을 수 있고, 이러한 과정을 마운트한다고 의미한다.
-
컴포넌트 마운팅 생애주기
- 컴포넌트가 마운트 될 경우
- constructor(props)
- componentWillMount() : 컴포넌트가 렌더링 되기 적전에 호출
- render()
- componentDidMount() : 컴포넌트가 렌더링된 직후에 호출
- 컴포넌트가 언마운트 될 경우
- componentWillUnmount()
- 컴포넌트가 마운트 될 경우
-
보통 DOM을 처리해야 하는 경우는 컴포넌트가 렌더링 된 후에 처리해야 하기 때문에 componentDidMount() 함수를 사용
-
초기 API 요청의 경우 둘 다 사용 가능
-
위에서 시작한 프로세스들은 componentWillUnmount()에서 종료를 해야 함
- 컴포넌트의 상태가 바뀌거나 부모로부터 새로운 프로퍼티가 도착한 경우에 호출되는 메소드
- 생애주기
- 상태가 변경된 경우
- shouldComponentUpdate(nextProps, netState) : true인 경우 생애주기 메소드들이 실행, 기본 값은 true
- componentWillUpdate(nextProps, netState) : 컴포넌트 갱신 직전에 호출
- render()
- componentDidUpdate(prevProps, prevState) : 컴포넌트 갱신 직후에 호출
- 새로운 프로퍼티가 도착한 경우
- componentWillReceiveProps(nextProps) : setState를 유일하게 쓸 수 있음
- shouldComponentUpdate(nextProps, netState)
- componentWillUpdate(nextProps, netState)
- render()
- componentDidUpdate(prevProps, prevState)
- 상태가 변경된 경우
- 기본적으로 부모가 갱신되면 자식들도 전부 갱신 된다.
- shouldComponentUpdate()를 사용하면 위 내용에 제한을 걸 수 있다.
- shouldComponentUpdate()는 아직 변경 전이기 때문에 이전 값들은 this.state와 this.props로 가져올 수 있다.
- 특정 컴포넌트의 자식들을 다룰 수 있는 방법을 제공
- 자식 노드노드들을 배열로 변환(toArray), map을 적용하거나, 자식을 이터레이션하거나, 자식 수를 셀 수 있다.
- React.Children.only 를 사용하면 오직 한 자식만 표시하는 검사할 도 있음.
- props.children 를 통해서 자식 elements를 전달 받을 수 있음
- 자세한 건 https://reactjs.org/docs/react-api.html#reactchildren 참고
- 요즘은 웬만한 건 다 표준으로 제공해주기 때문에 표준을 우선 쓰자.
- https://developer.mozilla.org/ko/docs/Web/API/Fetch_API
- IE에서는 아직 지원이 안되기 때문에 폴리필을 사용
- 책에 있는 내용 참고
- 고차 컴포넌트는 리액트 컴포넌트를 인자로 받아서 다른 리액트 컴포넌트를 반환하는 함수
- 인자로 받은 컴포넌트를 상태를 관리하는 컴포넌트나 다른 기능을 부가하는 컴포넌트로 감싸서 돌려줌
- 기능을 재활용하고 컴포넌트 상태나 생애주기 관리를 추상화할 수 있는 훌륭한 방법
- 리액트 기본 상태 관리 기능만으로 훌륭한 애플리케이션 개발은 가능
- 규모가 커지면 사람의 두뇌로 이해하기 어렵게 됨
- 상태를 리액트 밖에서 관리하면 리액트에 존재하는 클래스 컴포넌트의 필요성이 줄어든다.
- 이 말은 애플리케이션 안에서 리액트 상태나 setState 를 전혀 사용하지 않는다는 의미
- 대부분의 컴포넌트를 상태가 없는 함수형 컴포넌트로 제작이 가능
- 이해하기 쉽고 테스트하기 쉬운 구조 작성이 가능
- 데이터 흐름을 한 방향으로 유지하기 위해 페이스북에서 설계한 디자인 패턴
- 상태가 없는 함수형 컨포넌트는 순수 함수
- 리액트가 작동하는 방식을 보완하는 웹 애플리케이션의 아키텍처를 잡는 방법을 제공
- 스토어: 리액트 밖에서 애플리케이션의 상태 데이터를 저장하고 관리
- 액션 : 사용자의 요청, 변화를 일으키는 명령과 데이터를 제공
- 디스패처 : 중앙 제어 컴포넌트, 액션을 가져와 분배, 한 개만 존재
- 액션이 발생하면 디스패처에서 액션을 queue에 넣는다. queue에 액션이 있다면 디스패처에서 액션을 가져와서 적절한 스토어에 매칭을 시킨다. 스토어는 해당 액션의 명령과 데이터로 상태를 변경하고 뷰를 갱신한다.
- 플럭스의 액션과 상태 데이터는 변경이 불가
- 변경이 발생하기 위해서 액션이 필요
- 뷰는 상태 관리가 없기 때문에 상태 없는 함수형 컴포넌트로 생성
- 액션은 스토어가 상탤르 변경할 때 사용할 명령과 데이터를 제공
- 액션 생성기는 액션을 만들 때 필요한 이런저런 사항을 추상화해주는 함수
- 액션 자체는 type 이라는 필드만 들어 있으면 되는 객체
- 액션은 스토어에 필요한 정보를 담을 수 있다.
- Flux 어플리케이션의 중앙 허브로 모든 데이터의 흐름을 관리
- 스토어의 콜백을 등록, 액션을 스토어에 배분해주는 간단한 작동 방식
- 단 한개만 존재한다.
- 애플리케이션의 로직과 상태 정보를 담는 객체
- MVC 패턴의 모델과 비슷
- 현재 상태 데이터는 프로퍼티를 통해 얻을 수 있다.
- 스토어가 상태 데이터를 변경하기 위해 필요한 모든 정보는 액션 안에 들어 있다.
- 스토어는 타입에 따라 액션을 처리하고 액션을 처리하면서 상태를 적절히 갱신
- 데이터가 바뀌면 스토어는 이벤트를 발생시켜서 자신을 구독하는 뷰에 데이터가 변경되었다는 사실을 통지한다.

