엔코드 - 세미나 특집

프론트엔드에 대해 (feat.React)

플랫폼 : (소스코드가 돌아가는 곳) 브라우저

탄생 배경

• 아이폰이 나오기 이전에는 모든 서비스의 클라이언트는 브라우저를 의미
  • 백엔드 개발자는 JQuery만으로도 웹 브라우저에서 동작하는 View 소스 코드를 작업할 수 있었다
• 클라이언트의 기기가 다양해지며 백엔드에서는 데이터와 관련한 로직만을 처리해주고, 각 클라이언트가 서비스가 돌아갈 화면을 만들어주는 시대가 열림
  • Restful API의 등장
• 프론트엔드의 분업으로 퍼포먼스의 차이가 생기기 시작
  • 프론트엔드 단에 설계라는 개념의 등장
    • 이전에는 백엔드 개발자의 의식의 흐름대로 개발이 진행되는 측면
• 브라우저의 발전
  • node V8 엔진의 탄생
    • node.js를 중심으로 프론트엔드 테크 스택이 독립적으로 발전

개발 환경

트랜스 파일러 : 바벨

ECMAScript2015(ES6+) 이전 버전의 언어만 사용하는 브라우저들에게 그들의 언어로 변환해주는 모듈

번들러 : 웹팩

패키지 매니저로 인해 끌려온 의존성 모듈들 중에서 실제 사용하는 소스 코드만 번들링해주는 역할

패키지 관리자 : npm

CRA

트랜스 파일, 번들 기능을 사용하기 위해 관례적으로 설정을 해야하는 불편함이 있었고, 이를 이미 설정한 보일러 플레이트 프로젝트를 생성

리액트의 특징

컴포넌트 생성 주기

컴포넌트가 생성되고 소멸되기까지 호출되는 함수가 존재하며, 리액트 컴포넌트 클래스를 상속하는 모든 컴포넌트가 가지고 있다.

데이터 바인딩

• 2 way binding : 누구나 데이터를 바꿀 수 있음 (ex. 앵귤러)
• 1 way binding : 누구도 데이터를 바꿀 수 없음

리액트의 데이터

• state
  • 상태
  • 자신만이 가지고 있으며 자신이 핸들링
  • 상태와 관련한 이벤트 핸들러를 자식들에게 내려준다
  • state가 변경되면 자식 컴포넌트는 다시 그려진다
    • 가상 DOM이 다시 그려지며 변경된 부분을 확인하여 변경하는 형태
    • 실제 DOM을 건들이지 않는다
• props
  • 부모의 상태 일부를 주입 받은 객체. 일반적으로 props.**으로 접근 가능
  • 불변의 값

redux에서 mobx로의 전환

redux

Flux 패턴

• store라는 하나의 큰 데이터가 존재
  • store 안에 store가 있어서 일부의 store만 수신 가능
• reducer에서만 데이터 핸들링이 가능
• 변경된 데이터는 dispatch(action)를 이용해서 전파가 가능
• action을 수신하고 있던 컴포넌트가 props로 데이터를 수신

흐름

1. 유저가 버튼을 클릭했다고 가정했을 때
2. 버튼 클릭 이벤트를 수신하는 action이 있고
3. 해당 action을 dispatch해주는 dispatcher가 있음
4. 이벤트는 reducer를 통해 판단되어
5. store를 변경(덮어 씌우고)
6. view는 store가 변경되었으므로 props가 변경되며 전달

mobX

Observer 패턴

Observer 패턴

• data
• data를 핸들링할 수 있는 action이라는 함수

흐름

1. observable라 정의된 data의 모음인 store가 있고

2. 컴포넌트는 observer가 된다

   • 사용자 이벤트를 수신
   • 데이터의 변경이 일어나야 하는데

3. 컴포넌트는 store 안에 있는 action 함수를 call하고

4. mobx 모듈에서 데이터를 변경하고 observing 하고 있는 곳에 알려준다

parent가 observer가 되고, child는 observer가 될 수도, 안 될 수도 있다

성능 최적화를 위해서는 child도 observer인 것이 좋다