- State 란?
리액트를 다루는 핵심 !
State는 props처럼 App 컴포넌트의 렌더링 결과물에 영향을 주는 데이터를 갖고 있는 객체지만,
props는 (함수 매개변수처럼) 컴포넌트에 전달되는 반면 state는 (함수 내에 선언된 변수처럼) 컴포넌트 안에서 관리된다는 차이가 있다.
props를 사용했는데도 state를 사용하는 이유는, 사용하는 쪽과 구현하는 쪽을 철저하게 분리시켜서 양쪽의 편의성을 각자 도모하는 것에 있다.
프로퍼티(props)란?
- 프로퍼티, props(properties의 줄임말) 라고 한다. - 상위 컴포넌트가 하위 컴포넌트에 값을 전달할때 사용한다.(단방향 데이터 흐름 갖는다.) - 프로퍼티는 수정할 수 없다는 특징이 있다.(자식입장에선 읽기 전용인 데이터이다.)
. State와 Props의 차이점
class App extends Component {
render() {
return (
<div className="App">
<Subject title="WEB" sub="월드와이드웹!"></Subject>
</div>
); }
}
위 코드는 State를 사용해 수정하기 전, 즉 Props만 사용했을 때 App 컴포넌트의 모습이다.
화면에 출력되는 내용은 완전히 똑같지만, props 데이터를 사용자에게 노출되는 부분에 직접 적는 것이 아니라 State를 통해 참조했다는 차이가 있다. 즉,
사용자가 알 필요가 없는 데이터를 내부에서 은닉하는 것. 즉, 캡슐화를 통해 코드를 리펙토링 하는 것이 좋은 사용성을 만드는 핵심이다.
대표적인 3가지 리렌더링 조건
- Props 변경 (=> properties의 줄임말)
- State 변경
- 부모 컴포넌트 렌더링
*Props 변경
- Props 업데이트가 일어나면 리렌더링을 한다.
- Props가 변경되는 건 부모 컴포넌트의 State도 변경이 일어난다는 의미이다.
- 부모 컴포넌트의 State 변경이 발생하면 Props도 업데이트되고,모든 하위 컴포넌트에 대해 리렌더링이 발생한다.
*State 변경
- State 업데이트가 일어나면 리렌더링을 한다.
- 리액트에서 State 값이 변경되면 관련 컴포넌트들을 전부 리렌더링 한다.
- 리액트는 변화를 바로바로 감지하여 화면에 변경사항을 보여주기 때문이다.
*부모 컴포넌트 렌더링
부모 컴포넌트가 렌더링을 하면 그 자식 컴포넌트들은 모두 리렌더링 한다.
Props와 같은 원리이다.
- 돔(DOM)이란?
DOM(Document Object Model)은 MDN에 따르면 HTML, XML 문서의 프로그래밍 interface라고 한다. 쉽게 이해하면, 웹 페이지를 이루는 요소들(태그 등)을 자바스크립트가 이용을 할 수 있게 브라우저 내에서 트리 구조로 만든 객체 모델이라고 생각하면 될 것 같다.
즉, DOM은 HTML, XML 등의 문서와 JavaScript를 이어준다. - VirtualDOM (가상돔)
DOM에 대한 간단한 이해는 하였다. 그렇다면 리액트에서 사용하는 ReactDOM은 도대체 또 무엇일까? ReactDOM은 VirtualDOM이라고 한다. ReactDOM에 대해 알아보기 전에 VirtualDOM이 무엇인지 먼저 알아보자.
Instagram이나 Facebook, YouTube같은 홈페이지를 생각해보자. 이러한 서비스들은 스크롤이 무한에 가깝게 계속 내려가며 스크롤이 될 때마다 새로운 데이터들을 서버에서 불러온다. 불러온 데이터에 따라서 UI는 계속해서 업데이트 될 것이다. 수많은 Document의 elements를 가진 서비스들이 계속해서 데이터가 실제 DOM에 직접적으로 접근하여 업데이트 된다면 이는 분명 무리가 될 것이라고 판단이 된다. 이는 곧 서비스의 이슈로 이어질 것 같다고 생각이 든다. DOM 자체는 빠르지만 페이지의 리페인트가 계속해서 발생한다면 속도가 늦춰질 것이라고 생각이 든다.
실제 DOM에 접근하게 되면 위와 같은 문제가 발생한다. 이를 해결하기 위해 나타난 것이 Virtual DOM이다.
실제 DOM에 직접 접근하는 대신에, 이를 자바스크립트 객체로 구성하여 DOM을 추상화하여 사용하는 방식이다.
React를 사용할 때에는 React가 모두 처리를 해주기 때문에, DOM API를 직접 구현하지 않아도 된다.
Virtual DOM의 반영
특정 홈페이지의 데이터가 변했다고 가정을 했을 때, Virtual DOM은 다음과 같은 플로우를 가진다.
기존 페이지의 데이터 버전을 v1, 바뀐 페이지의 데이터 버전을 v2라고 하자.
데이터가 업데이트 되면, v2의 UI 전체를 Virtual DOM을 리렌더링한다.
그렇다면 기존에 Virtual DOM에 있던 v1과 바뀐 현재의 v2를 비교한다. (Virtual DOM끼리 비교를 하는 것이다.)
비교를 한 뒤, 바뀐 일부분만 실제 DOM에 적용이 된다.
실제 DOM에서 데이터가 업데이트 될 때마다 계속해서 작은 규모로 리플로우를 여러 번 하는 것보다 VirtualDOM을 이용하여 실제 DOM에서는 크게 한 번 리플로우 되는 것이 성능을 비교 했을 때, 성능 향상을 가져오게 된다.
- 서버리스란?
서버리스는 직역하자면 "서버가 없다"라는 의미가 있다. 하지만 실제로 서버가 없는건 아니다.
대신 특정 작업을 수행하기 위해 컴퓨터나 가장머신에 서버를 설정하고, 이를 통해 처리하는 것이 아님을 의미한다. 그 대신, BaaS(Backend as a Servie) 혹은 FaaS(Function as a Service) 에 의존하여 작업을 처리하게 된다.
BaaS vs FaaS
-
BaaS (Backend as a Service)
보통 우리가 모바일이나 웹 어플리케이션을 만들게 될 때, 백엔드 서버 개발을 진행하게 된다. 서버 개발을 하다보면 고려할 사항이 꽤 많다. 대표적으로 유저가 늘어나게 되면 서버의 확장도 고려해야 하고, 보안성도 고려해야 한다. 그래서 탄생한 서비스가 Firebase 같은 BaaS 이다.
이 서비스에서는 앱 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜서비스 연동, 파일 시스템 등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현 할 수 있게 해주고, 비용은 사용 한 만큼 나가게 된다. 서버의 이용자가 순식간에 늘어나게 되어도 따로 대비를 안해줘도 알아서 확장이 된다.
BaaS 의 가장 큰 장점은 개발 시간의 단축, 서버 확장 작업의 불필요함이다. 따라서 백엔드에 대한 지식이 별로 없더라도, 아주 빠른 속도로 개발이 가능하다.
그렇다면 BaaS 의 단점은 무엇인가. -
클라이언트 위주의 코드
ㅡ> BaaS 를 사용하면 백엔드 로직들이 클라이언트쪽에 구현이 된다. 데이터단의 로직이 변경되면 클라이언트 코드의 수정이 이루어진다. 그렇게 되면 재배포를 해야되고 웹어플리케이션이라면 JS를 새로 받아야한다. 그렇다면 모바일 앱이라면, 앱 업데이트를 해야되고 상황에 따라 구버전 사용자를 강제 업데이트해야 하는 일이 발생 할 수도 있다. -
가격
ㅡ> Firebase 의 경우 초반에는 무료라 소규모 프로젝트에는 매력적인 장점이다. 하지만 앱의 규모가 커지면 가격이 꽤 비싸진다. 실시간 데이터베이스에 10G 가 쌓이고, 한 달 전송되는 데이터의 양이 20G 정도면 데이터베이스 비용으로만 $70 가 발생한다. 참고로 클라우드 컴퓨팅 호스팅을 해주는 서비스 Vultr 의 가격대를 보면, $10 이면 40GB SSD, 2000GB 월 대역폭을 사용 할 수 있다.
복잡한 쿼리가 불가능함
- FaaS (Function as a Service)
FaaS 는 프로젝트를 여러개의 함수로 쪼개서 매우 거대하고 분산된 컴퓨팅 자원에 준비해둔 함수를 등록하고, 이 함수들이 실행되는 횟수, 시간만큼 비용을 내는 방식이다.
우리가 등록한 함수는 특정 이벤트가 발생했을때 실행된다.
주기적으로 실행되게끔 설정 할 수 있다. 5분마다, 1시간마다, 하루마다 이런식으로 가능하고 크롤링 작업, 주기적 처리를 할 때 좋다.
웹 요청을 처리 할 수도 있다. 예를 들어 특정 URL 로 들어오면 어떠한 작업을 하게끔 할 수 있다. 이를 통해 백엔드 API 를 구성 할 수도 있다.
콘솔을 통하여 직접 호출 할 수도 있다.
- 장점
비용 : 특정 작업을 하기 위해 서버를 준비하고 하루종일 켜놓는것이 아니라, 필요할때만 함수가 호출되어 처리되며 함수가 호출된 만큼만 비용이 드므로, 비용이 많이 절약된다.
인프라 관리 : 네트워크, 장비 이런것들에 대한 구성 작업을 신경 쓸 필요가 없다.
확장성면에서 매우 뛰어나다. - 단점
모든 코드를 함수로 쪼개서 작업하다보니, 함수에서 사용할 수 있는 자원에 제한이 있다.
FaaS 제공사에 매우 의존하므로 AWS, Azure, Google 등의 FaaS 제공사에 강한 의존을 하게 된다. 갑자기 이 회사들이 망해버리면 매우 골치 아프게 된다.
비교적 신기술이라 해외에서는 관련 자료들을 볼 수 있는 반면, 국내에서는 관련 자료를 찾아보기 힘들다.
