[모던리액트]- 2장 (2) 클래스 컴포넌트와 함수 컴포넌트

nais·2024년 8월 24일

모던리액트

목록 보기

2/6

클래스 컴포넌트

기본적으로 클래스 컴포넌트를 만들려면 클래스를 선언하고 extends 로 만들고 싶은 컴포넌트를 extends 해야한다
extends 구문에 넣을 수 있는 클래스는 두가지

React.Component
React.PureComponent

constructor() : 컴포넌트 내부에 이 생성자 함수가 있다면 컴포넌트가 초기화 되는 시점에 호출됨, 해당 함수에 super() 가 있다면 상속받은 상위 컴포넌트의 생성자 함수를 먼저 호출해 필요한 상위 컴포넌트에 접근 가능
Props : 함수에 인수를 넣는 것과 비슷하게 , 컴포넌트에 특정 속성을 전달하는 용도로 쓰인다.
state : 클래스 컴포넌트 내부에서 관리하는 값은 항상 객체여야만 한다. 이 값에 변화가 있을 때 마다 리렌더링 발생
메서드 : 렌더링 함수 내부에서 사용되는 함수이며, 보통 DOM에서 발생하는 이벤트와 함께 사용된다. 만드는 방식의 아래 3가지와 같다

(1) constructor 에서 this 바인드
일반적으로 자바스크립스에서 일반 함수를 호출 할 때 this 는 전역 객체가 바인딩된다. 따라서 생성된 함수에 bind 를 활용해 강제로 this 를 바인딩 해야한다.

(2) 화살표 함수를 사용하기
일반적으로 화살표 함수는를 사용한다면 작성 시점에 this가 상위 스코프로 결정되기 때문에 굳이 바인딩 하지 않고 사용 가능

(3) 렌더링 함수 내부에서 함수를 새롭게 만들어 전달
```
const onClick = {()=> this.handleClick()} 
```
이와 같이 사용하게되면 매번 렌더링이 일어 날 때 마다 새로운 함수를 생성해 할당되기 때문에 최적화 수행이 어렵다 따라서 지양하는 것이 좋다

클래스 컴포넌트의 생명주기 메서드

생명주기 메서드가 실행되는 시점은 크게 3가지로 나눌 수 있다

마운트(mount): 컴포넌트가 마운팅(생성) 되는 시점
업데이트(update): 이미 생성된 컴포넌트의 내용이 변경(업데이트)되는 시점
언마운트(unmount): 컴포넌트가 더 이상 존재하지 않는 시점

각 생명 주기 메서드를 알아보자

render()

생명주기 메서드 중 하나로, 클래스 컴포넌트의 유일한 필수 값이다.
컴포넌트가 UI를 렌더링 하기 위해 쓰이고 마운트와 업데이트 과정에서 일어난다.
항상 순수하고 부수효과가 없어야 한다 => state 를 변경하는 일은 클래스 컴포넌트의 메서드나 다른 생명주기 메서드 내부에서 발생해야함

componentDidMount()

컴포넌트가 마운트되고 준비되는 즉시 실행된다
state 가 변경되고 그 즉시 다시 한번 렌더링을 시도
생성자 함수에서 할 수 없는 것, API 호출 후 업데이트, DOM에 의존적인 작업(이벤트 리스너 추가) 등을 하기 위해서 this.setState를 허용한다

componentDidUpdate()

컴포넌트 업데이트가 일어난 직후 바로 실행된다
state나 props 의 변화에 따라 DOM을 업데이트하는 등에 쓰임
this.setState 사용할 수 있다 (적절한 조건문으로 감싸야지 props 가 변경되는 매 순간마다 실행 될 수도 있음

componentWillUnmount()

컴포넌트가 언마운트 되거나 더 이상 사용되지 않기 직전에 실행
메모리 누수나 불필요한 작동을 막기 위해서 함수 호출에 최적의 위치
이 메서드 내에서는 this.setState 호출 불가능

shouldComponentUpdate()

state나 props 의 변경으로 리액트 컴포넌트가 다시 리렌더링 되는 것을 막기위한 메서드
state 변화에 따라서 컴포넌트가 리렌더링 되는것은 자연스러운 현상이기에 성능 최적화 상황에만 고려하는 것이 좋다

클래스 컴포넌트와 함수 컴포넌트의 생애주기

리액트의 클래스형 컴포넌트와 함수형 컴포넌트의 생애주기는 비교될 수는 있는데,
함수형 컴포넌트는 React Hooks 를 사용해 생애주기 메서드와 비슷하게 구현가능

(즉, 생명주기 메서드는 React.Component에서 오는 것이기 때문에 클래스 컴포넌트가 아닌 이상 생명주기 메서드를 더는 사용할 수 없다는 뜻 )

클래스 컴포넌트의 한계

어떠한 문제점 때문에 함수 컴포넌트에 훅을 도입한 새로운 패러다임을 만든것일까?

1) 데이터의 흐름을 추적하기 어렵다
생명주기 메서드에서 state의 흐름을 추적하기 매우 어렵다. 서로 다른 메서드에서 state 의 업데이트가 일어날 수 있으며 코드 작성시 메서드의 순위가 강제되는 것이 아니기 때문이다.

2) 애플리케이션 내부 조직의 재사용이 어렵다
컴포넌트로 다른 컴포넌트를 감싸거나, props를 넘겨주는 등 공동 로직이 많아지거나 props 가 많아지는 래퍼 지옥에 빠져들 가능성이 커지고 애플리케이션 규모가 커질 시 재사용 로직도 많아지기 때문이다.

3) 기능이 많아질수록 컴포넌트의 크기가 커진다
기능이 많아질수록 또 내부에서 처리하는 데이터 흐름이 복잡해져 생명주기 메서드 사용이 잦아지는 경우 컴포넌트의 크기가 기하 급수적으로 커진다

4) 클래스는 함수에 비해 상대적으로 어렵다
자바스크립트는 프로토타입 기반의 언어이기에 개발자들은 클래스보다 함수에 더 익숙하 대부분의 언어와 다르게 동작하는 this도 한몫한다

5)코드 크기를 최적화 하기 어렵다
사용하지 않는 메서드들도 트리쉐이킹 되지 않고 컴포넌트 빌드 시 그대로 포함된다. 번들링을 최적화하기에 불리한 조건

6) 핫로딩을 하는데 상대적으로 불리하다

핫로딩이란 ?
코드에 변경 사항이 발생했을 때 앱을 다시 시작하지 않고도 해당 변경된 코드만 변경 사항을 빠르게 적용하는 기법을 말함 흔히 이 기능은 빌드해서 실행하는 것이 아닌 개발 단계에서 많이 사용된다.

우리가 개발 시 애플리케이션을 실행한 채로 코드의 수정 내용이 바로바로 적용되는 것은 이 핫로딩 덕분인데 이 핫로딩 관점에서도 클래스 컴포넌트가 불리하다.
함수 컴포넌트는 핫 로딩이 일어난 뒤에도 변경된 상태값이 유지되지만, 클래스 컴포넌트는 핫로딩이 일어나면 바로 다시 기본값이 0으로 돌아간다.

클래스 컴포넌트는 최초 렌더링 시에 instance를 생성하고, 그 내부에서 state 값을 관리하는데, 이 instance 내부에 있는 render 를 수정하게 되면 이를 반영할 수 있는 방법은 오직 instance 를 새로 만든 것 뿐이다. 그렇기에 당연히 초기화 될 수 밖에 없다.

함수 컴포넌트는 state를 함수가 아닌 클로저에 저장해 두므로 함수가 다시 실행해도 state 를 잃지 않고 다시 보여줄 수 있게 된다.