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 변경
*State 변경
*부모 컴포넌트 렌더링
부모 컴포넌트가 렌더링을 하면 그 자식 컴포넌트들은 모두 리렌더링 한다.
Props와 같은 원리이다.
실제 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 Service)
보통 우리가 모바일이나 웹 어플리케이션을 만들게 될 때, 백엔드 서버 개발을 진행하게 된다. 서버 개발을 하다보면 고려할 사항이 꽤 많다. 대표적으로 유저가 늘어나게 되면 서버의 확장도 고려해야 하고, 보안성도 고려해야 한다. 그래서 탄생한 서비스가 Firebase 같은 BaaS 이다.
이 서비스에서는 앱 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜서비스 연동, 파일 시스템 등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현 할 수 있게 해주고, 비용은 사용 한 만큼 나가게 된다. 서버의 이용자가 순식간에 늘어나게 되어도 따로 대비를 안해줘도 알아서 확장이 된다.
BaaS 의 가장 큰 장점은 개발 시간의 단축, 서버 확장 작업의 불필요함이다. 따라서 백엔드에 대한 지식이 별로 없더라도, 아주 빠른 속도로 개발이 가능하다.
그렇다면 BaaS 의 단점은 무엇인가.
클라이언트 위주의 코드
ㅡ> BaaS 를 사용하면 백엔드 로직들이 클라이언트쪽에 구현이 된다. 데이터단의 로직이 변경되면 클라이언트 코드의 수정이 이루어진다. 그렇게 되면 재배포를 해야되고 웹어플리케이션이라면 JS를 새로 받아야한다. 그렇다면 모바일 앱이라면, 앱 업데이트를 해야되고 상황에 따라 구버전 사용자를 강제 업데이트해야 하는 일이 발생 할 수도 있다.
가격
ㅡ> Firebase 의 경우 초반에는 무료라 소규모 프로젝트에는 매력적인 장점이다. 하지만 앱의 규모가 커지면 가격이 꽤 비싸진다. 실시간 데이터베이스에 10G 가 쌓이고, 한 달 전송되는 데이터의 양이 20G 정도면 데이터베이스 비용으로만 $70 가 발생한다. 참고로 클라우드 컴퓨팅 호스팅을 해주는 서비스 Vultr 의 가격대를 보면, $10 이면 40GB SSD, 2000GB 월 대역폭을 사용 할 수 있다.
복잡한 쿼리가 불가능함
우리가 등록한 함수는 특정 이벤트가 발생했을때 실행된다.
주기적으로 실행되게끔 설정 할 수 있다. 5분마다, 1시간마다, 하루마다 이런식으로 가능하고 크롤링 작업, 주기적 처리를 할 때 좋다.
웹 요청을 처리 할 수도 있다. 예를 들어 특정 URL 로 들어오면 어떠한 작업을 하게끔 할 수 있다. 이를 통해 백엔드 API 를 구성 할 수도 있다.
콘솔을 통하여 직접 호출 할 수도 있다.