DOM (Document Object Model)? • 객체로 문서 구조를 표현하는 방법으로 XML이나 HTML로 작성 DOM을 조작한다? 1. Element를 선택한다. • id, class, tag name으로 HTML의 Element를 선택한다. • $(“ “) 2. 선택한 Element를 효율적으로 제어한다. • 선택한 Element (예를 들어, <div class=“abc”> … </div>)에 속성, 새로운 element, event 등을 추가/수정/삭 제할 수 있다. • $(“ “).css( … ), $(“ “).attr( … ), $(“ “).click( … ) …
해당 Element와 가장 가까운 Element를 선택한다. jQuery에 대해.. • jQuery에서 .closest()를 사용하는 경우 • 아래는 박스를 만들고 그 중에 하나를 클릭하면 상위 Element에 Class를 지정하는 경우이다. div ul li li li a class=“item” class=“box” Click class=“Dog” • closest(“div”)만 봐서는 무슨 의미인지 알 수 없다 → HTML 코드를 확인 해야 한다. 여기서 문제는... • 만약 개발이 끝나고, 애니메이션을 위한 div 태그를 a태그 상위에 넣자는 의견이 나온다면..?
개발 시 제대로 된 Convention을 정해 놓지 않으면 복잡한 코드가 될 수 있다. • 이후에 유지보수가 힘들어진다. DOM을 다루는 효율적이고 강력한 도구이다. 그래서 유지보수가 힘들다. • 이것 역시 제대로 된 convention을 정해 놓고 개발한다면 구조화된 결과물을 만들 수 있다. • ex) Javascript의 module pattern을 이용 • 하지만 구조화를 위해서 HTML을 따로 분리하고, 위와 같은 추가적인 pattern이 필요하고 관리가 쉽지 않다. 구조를 다루기 쉽지 않다. 감춰져 있는 부분 return한 요소만 외부에서 사용할 수 있다. // Hello World // “undefined” // Type error 발생 Module pattern
배경 • Web에 발전에 따라 Front-end 단의 규모도 커지게 됨 • 기존에 jQuery를 많이 사용하고 있었지만, DOM을 효율적으로 다룰 뿐, 구조적인 대안이 될 수 없었다. SPA(Single Page Application)의 등장 • SPA : 서버로부터 완전한 새로운 페이지를 불러오지 않고, 현재의 페이지를 동적으로 User와 소통하는 웹 애플리케이션 • ex) Backbone과 AngularJS Request Response
기반의 프레임워크가 존재 • 데이터가 변경되면, 이를 View에 반영하여 업데이트 데이터가 변할 때 기존 뷰를 날리고 새로 렌더링한다. 위 JSON 데이터와 HTML 코드에서 likes class 부분의 2를 업데이트 한다고 하면, DOM 트리에서 해당하는 노드를 찾고, 업데이트 하는 과정을 거칠 것이다. React 개발 팀은 기존 뷰를 날리고 그냥 새로 렌더링하면 어떨까? 라는 아이디어를 제시 -> 하지만 이것은 브라우저의 성능과 메모리를 많이 차지
표현하는 방법으로 XML이나 HTML로 작성한다. React 개요 • 실제 DOM에 접근하여 조작하는 대신, 이를 추상화한 자바스크립트 객체를 구성하여 사용 (DOM의 가벼운 사본) Virtual DOM 이전 DOM 트리 새로운 DOM 트리 업데이트 될 DOM 노드 • React에서 데이터가 변하여 웹 브라우저에 실제 DOM을 업데이트할 때 다음 3가지 절차를 거친다. 1. 데이터를 업데이트하면 전체 UI를 Virtual DOM에 리렌더링 2. 이전 Virtual DOM에 있던 내용과 현재 내용 비교 3. 바뀐 부분만 실제 DOM에 적용
태그 형식을 문자열로 반환하는 템플릿과 달리, React는 컴포넌트(Component)라는 것을 사용하여 렌더링한다. 컴포넌트(Component)? • React에서 특정 부분이 어떻게 생길지 정하는 선언체로, 재사용이 가능한 API로 수많은 기능들을 내장하고 있다. • 컴포넌트 하나에서 해당 컴포넌트의 생김새와 작동 방식을 정의 렌더링(Rendering)? • 사용자 화면에 View를 보여주는 것 React는 ‘초기 렌더링’과 ‘조화 과정’을 통해 성능을 아낀다. 렌더링 HTML 마크업 <div>…</div> DOM 주입 1. 초기 렌더링은 Component의 render 함수를 통해 시작된다. render() 2. HTML 마크업에 필요한 데이터와 함께 DOM에 주입한다. 3. DOM을 화면에 그림으로써 사용자에게 보여준다. 4. 만약 데이터의 변화가 생길 경우 조화 과정을 거쳐 리렌더링 한다. 리렌더링
쓰는 Library이다. • 즉, 서버 통신을 위한 Ajax, 다른 컴포넌트 사용을 위한 Routing, 데이터 모델링 등과 같은 기능이 없다. • 직접 구현해야 한다. • 가볍기도 하고(성능이 좋다) 다른 Framework 또는 Library와 같이 사용할 수 있다는 장점 그럼 React가 jQuery보다 좋은 건가? React를 사용하면 무조건 빠르다!? 우리는 다음 문제를 해결하려고 리액트를 만들었습니다. “지속적으로 데이터가 변화하는 대규모 어플리케이션 구축하기” React 매뉴얼 중.. 그럼 jQuery 대신 React를 쓰는 이유? • 언급했듯이, 규모가 커짐에 따라 데이터 변화에 따른 View 업데이트의 간결성 • 컴포넌트의 재사용성 • 모듈화 등의 이점이 있기 때문에 사용한다. • React가 jQuery보다 좋다는 것은 오해다. • 오히려 jQuery가 생산성이나 성능이 더 우수할 수 있다. • 사실 React는 View를 위한 Library이기 때문에 DOM을 핸들링하는 jQuery와 좋다/나쁘다를 비교하는 것은 무의미하다.
제작해보고 느낀 점(?) React jQuery • 확실히 jQuery가 React보다는 생산성이나 코드 양이 적다. • 하지만 쉽게 DOM을 제어하는 로직을 짜다 보니, 모듈별로 분리하기가 애매했다. • 작은 사이즈의 프로젝트에서는 jQuery로 하는 것이 좋을 것 같고, 큰 사이즈에서는 React와 같은 라이브러리나 프레임워크를 사 용하는 것이 이후 유지보수 면에서 좋을 것 같다.
Prettier의 세부적인 rule을 정의 • 프로젝트의 package.json 파일에서 설정 • extends : airbnb의 규칙과 prettier 적용 • parser : ES6의 arrow function을 사용하기 위해 추가 • rules : 세부 규칙을 커스터마이징 하기 위해 정의 • env : document.~” 사용하기 위해 추가
프로젝트를 생성할 때 필요한 Webpack, Babel의 설치 및 설정 과정을 생략하고 바로 간편하게 프로젝트 작업 환경을 구축해 주 는 도구 • yarn을 사용한다면 • $ yarn create react-app <project-name> • yarn을 사용하지 않는 경우(npm 사용) • $ npm init react-app <project-name> 생성하면 오른쪽 화면과 같은 프로젝트 구조가 생성된다. • src 폴더 하위에는 기본적인 파일들만 구성되어 있다. • App.js, App.css • index.js, index.css • serviceWorker.js • … • 좀 더 구조적으로 컴포넌트를 관리하기 위해서는 개선이 필요
위에서 언급한 label, input, button 등 Atoms는 따로 사용될 때는 그리 유용하지 않다. • Atoms를 결합해서 사용할 때 비교적 의미 있는 요소가 된다. Organisms • 여러 개의 Molecules로 구성된 것 • ex) logo, navigation search form, social media channel이 합쳐진 구성
Container라고 불림 • 앱의 상태(Redux state)를 제어하는 역할 • Redux의 store 접근은 오직 container를 통해서만 이루어진다. • Dumb component 또는 Presentional component라고 불림 • 상위 component로부터 props를 전달받아 보여주는 역할 Container(smart component) Component(dumb component) Atomic Design 적용 모습
이루어진다.” Store Action dispatch subscribe 구성 요소 • Store: 애플리케이션의 state 값들을 저장하고 있다. • Action: state 변화를 일으킬 때 참조하는 객체 • Dispatch: Action을 Store에 전달하는 과정 • Reducer: State를 변화시키는 로직이 있는 함수 • Subscribe: Store의 state 값이 필요한 컴포넌트는 store를 구독한다. React state 관리 라이브러리 state 업데이트 관련 로직을 다른 파일로 분리하여 관리 가능 Component끼리 같은 state를 공유해야 할 때도 여러 Component를 거치지 않고 쉽게 전달하거나 업데이트 가능
리듀서를 모두 한 파일에서 모듈화 하여 관리하는 방식 store-modules-base.js Action의 타입을 정의 정의한 Action 타입에 따라 함수(dispatch)를 생성하고, Component 파일 내에서 이 함수를 호출하여 사용 초기의 state Reducer 부분이다. dispatch된 Action에 대해 비즈니스 로직을 수행 실제 state를 조작하는 부분
index.js에서 시작한다. • Proivder는 Redux Store와 연결하는 부분이다. • BrowserRouter는 여기서 다루지 않지만, Routing을 위해 추 가한 부분 • Entry Point에 App 컴포넌트가 붙게 되고 • App 컴포넌트 하위에 있는 여러 컴포넌트가 붙는다. • (Atomic Design으로 구성한 컴포넌트들이 될 것이다.) • 각 컴포넌트들은 LifeCycle을 기반으로 동작한다.(뒷장에 계속)
• 컴포넌트를 새로 만들 때마다 호출되는 클래스 생성자 메서드 constructor getDerivedStateFromProps render componentDidMount • props에 있는 값을 state에 넣을 때 사용하는 메서드 • 우리가 준비한 UI를 렌더링하는 메서드 • 컴포넌트가 웹 브라우저 상에 나타난 후 호출하는 메서드
경우다. 1. props가 바뀔 때 2. state가 바뀔 때 3. 부모 컴포넌트가 리렌더링될 때 4. this, forceUpdate로 강제로 렌더링을 트리거할 때 • 컴포넌트의 업데이트 작업이 끝난 후 호출 • 마운트 과정과 업데이트 과정 모두 호출된다. • props의 변화에 따라 state 값에도 변화를 주고 싶을 때 사용 • 컴포넌트가 리렌더링을 해야 할지 말아야 할지를 결정 • true 또는 false 반환하는데, false를 반환하면 작업을 중지한다(컴포넌트가 리렌더링하지 않는다) • 특정 함수에서 this.forceUpdate() 함수 호출하면 이 과정을 생략하고 바로 render 함수 호출 • 컴포넌트를 리렌더링 • 컴포넌트 변화를 DOM에 반영하기 바로 직전에 호출 getDerivedStateFromProps shouldComponentUpdate render getSnapshotBeforeUpdate componentDidUpdate
chanyounglee
twada
maaretp
masuda220
maruto
gam0022
qnighy
oniak3ibm
polpielladev
afilina
fukubaka0825
usagimaru
manfredsteyer
malarkey
aleyda
chriscoyier
gr2m
holman
sonatard
philhawksworth
eileencodes
erikaheidi
vanstee
caitiem20
