11. React를 쓰는 이유
● 렌더링 시점을 직접 제어하지 않아도 됨
● 그러면서도 Virtual DOM으로 성능을 확보함
● Angular 쓰기 싫어서
● 그리고…
12.
13. React-Hot-Loader
● 재시작 없이 State를 유지한 상태로 변경된 코드를 반영
● 생산성을 높이는데 굉장히 효과적
● react + webpack + hot-loader 등이 필요
● boilerplate 등 참고할 수 있는 예제 많음
https://github.com/gaearon/react-hot-loader
15. React Hot Loader 사용 흐름
클라이언트React Hot Loader 서버
초기 클라이언트 리소스 전달
HTTP
변경사항 전달
Websocket
변경사항 감지
변경된 부분
Webpack 빌드
16. Phonegap에서 React-Hot-Loader 적용하
기
● 실제 디바이스에서 Charles나 Fiddler 등으로 프록시 사용
● localhost 대신 Hosts 파일 수정을 통해 개발 도메인으로 접
근
- ex) 127.0.0.1 dev.hogangnono.com
● webpack 설정에서 위의 도메인으로 모듈을 띄움
17.
18.
19. 두 배 빨라진 개발환경
출처: https://pixabay.com/ko/%EC%B9%98%ED%83%80-%EB%8F%99%EB%AC%BC-%ED%8F%AC%EC%9C%A0-%EB%8F%99%EB%AC%BC-%EB%A0%88%EC%98%A4-%ED%8C%8C-%EB%93%9C-%EB%8F%99%EB%AC%BC%EC%9B%90-%EC%9B%90%EC%A0%95-%EC%97%AC%ED%96%89-48013/
22. React-Router
● 많은 곳에서 사용하고 있기 때문에 큰 문제는 없음
- 자잘한 문제가 있었지만 거의 해결됨
● Phonegap에서 사용시 Hash History 방식을 사용해야함
- 예) index.html#/main
● major 버전이 변경됨에 따라 사용법이 충격적으로 바뀜
- 1년전 버전 0.13, 지금 버전 v4.0.0-alpha…
34. React Isomorphic
● 서버에서 실행할 수 없는 로직은 분기처리 해야함
- window.alert, window.confirm 등
● Action 코드를 같이 사용하기 때문에 클라이언트와 서버에서
동시에 쓸 수 있는 XMLHTTPRequest 모듈 필요
40. React Native가 아니고?
● OSMU(One Source Multi Use) 불가능
● 부족한 플러그인
- 카카오톡, Fabric, Google Analytics 등 연동할 서비스가 너무 많음
● 네이티브라고 다 빠르고 좋진 않다는 교훈
- Titanium…
46. Native Page Transitions
● 기본 설정으로 사용하면 타이밍이 맞지 않아 같은 페이지가 반복 호
출되는 이슈 발생
● React-Router와 연계해서 트랜지션 타이밍을 맞춰야함
- onEnter 핸들러로 확인할 수 있음
라우팅 액션
Native Page
Transition
start()
라우팅 완료
Native Page
Transition
execute()
55. Phonegap 그 밖에…
● Swipe Back 등 네이티브 앱의 고유 동작을 모방함
● 기본 탑재 브라우저 성능 향상 가능
- 안드로이드는 Crosswalk, iOS는 WkWebview Engine
● 다양한 플러그인으로 보다 네이티브 앱처럼 만들 수 있음
- Fabric, PushPlugin, CustomURLScheme, Facebook, KakaoTalk,
CallNumber, Universal Clipboard 등
- http://cordova.apache.org/plugins/
- http://plugins.telerik.com/cordova
58. Write Once
Run Everywhere
출처: http://www.dailymail.co.uk/travel/travel_news/article-2812387/From-car-boat-15-seconds-155-000-Panther-car-hit-waves-45mph-s-18-month-waiting-list-buy-one.html
지금 들려드릴 얘기가 사장님들에게 혹시
“플랫폼 4개 만드는데 2명의 개발자만 있으면 된다”는 소리를 들릴 수 있을 것 같습니다.
여러분들은 아니겠지만, 여러분들의 사장님들은 그렇게 생각하실 수도 있어요…
보통의 경우라면 iOS, 안드로이드, 서버, 프론트앤드 등 적재적소에 개발자들이 배치돼서 프로젝트를 수행할 거에요.
이게 가장 일반적인 경우죠.
아무리 메시가 잘한다 한들, 저렇게 배치하면 경기 제대로 못할거에요.
그런데 개발은 어쩔 수 없이 해야하는 상황이 생깁니다.
우리 이와 같은 상황에 처한다면 필요한게 두 가지 있습니다.
첫 번째로 원소스 멀티유즈.
한 번의 삽질로 여러번의 삽질을 대체하는 것이죠. 모든 개발자들의 꿈이라고 할 수 있습니다.
두 번째는 제가 만든 말인데.. 원리소스 멀티유즈.
앞선 메시처럼 여러명이 할 일을 한 명이 다해야한다는 뜻입니다.
요새 뜨고 있죠. 풀스택 개발자라고…
굉장히 찾기 힘든 존재입니다.
저희는 불행인지 다행인지 창업자가 모두 조건을 갖춘 개발자라 시작할 수 있었습니다.
앞의 조건을 갖춘건지 뒤의 조건을 갖춘건지는 말하지 않겠습니다..
저희는 자바스크립트를 꽤 전문으로 다룬 개발자들이었습니다. 자바스크립트는 좋고, npm 패키지는 언어중에 가장 많으며, 어쩌고 저쩌고.. 하는 것들은 여기서 굳이 설명하지는 않겠습니다. 그래서 자바스크립트를 선택했는데, 가장 큰 이유는 한 개의 언어로 백앤드와 프론트앤드를 모두 커버하기 위해서였습니다.
그리고
자바스크립트의 장점이자 단점인 부분인데 선택지가 굉장히 많습니다.
저희는 React를 선택했습니다.
여러가지 이유가 있었죠. 전 직장인 카카오에서 쓰던게 백본에 자체 개발한 프레임워크였는데 모델이 바뀌고 나면 렌더링 메소드를 직접 호출해줘야하는 번거로움이 있었죠. React는 이 시점을 알아서 조절하고, Virtual DOM으로 성능도 확보했기도 했고, Angular와는 다르게 DOM이 뜨기 전에 로직을 읽을 수 있는 장점이 있었습니다. 페이스북이 적극적으로 사용한다는 것도 큰 장점이었어요.
그리고 가장 큰 이유는…
이거였어요.
React Hot Loader는 React, Webpack을 이용해서 재시작 없이 상태를 유지한 채로 변경된 코드를 반영할 수 있는 개발 환경을 만들어 줍니다. 개발 생산성에 엄청난 변화를 줄거라는 느낌이 확 왔죠. 기본적으로 문서나 샘플 코드가 잘 돼있기 때문에 프로젝트를 잘 찾아보시면 어렵지 않게 반영하실 수 있을겁니다.
그런데 문득 이런 생각이 들더라고요. 이거, 하이브리드 앱에도 적용할 수 있지 않을까?
이걸로 남들보다 두 배 빠른 개발환경을 얻었습니다. 지금도 저희 개발 속도에 큰 영향을 끼치고 있습니다.
개발 환경 셋팅은 이렇게 끝났고, 다음으로 필요한건 라우터 였습니다.
React Router는 React 컨셉을 잘 반영한 라우터로써, 현재로써는 유일무이한 선택입니다.
예전에는 몇가지 문제가 있었지만, 프로젝트가 활발히 진행되면서 대부분의 문제가 수정됐습니다. 예제나 문서도 잘 돼있기 때문에 어렵지 않게 사용할 수 있죠.
폰갭과 같이 사용할 경우에는 해시 히스토리 방식으로 사용해야 하는 것 정도만 신경쓰면 됩니다.
다만, 버전이 급격하게 올라감에 따라 사용법이 엄청나게 바뀐것이 저희를 고통스럽게 했습니다. 처음 만들기 시작했을 때 버전이 0.13이었는데 지금은 4버전이거든요… 자바스크립트에서 이런건 한 두개가 아니죠. 좀 있다가 또 설명해 드릴께요.
리액트 그 자체로는 View의 영역만 해결할 수 있습니다. 다른 프레임워크와 함께 쓸 수도 있겠지만, 이왕이면 페이스북이 제시한 Flux를 사용하면 좋겠죠.
Flux의 가장 큰 특징은 1 Way Binding이라고 볼 수 있죠. 예전에 백본을 썼을 때에는 View에서 Model을 직접 바꾸기도 했었는데, Flux 개념에서는 그렇게 할 수 없고 반드시 Actions을 통해서 모델을 변경하게끔 되어 있습니다. 자세한 설명은 사이트에서 보실 수 있고…
지금은 redux가 유명한 것 같지만, 저희가 개발을 시작할 때는 redux가 없었습니다. 저희는 대신 Alt를 선택했습니다.
그렇지만 지금 선택하라고 해도 Alt를 선택할지도 모르겠습니다.
Alt는 굉장히 간단합니다.
액션을 구현하는 코드인데요, 보통 여기서 API 콜이 일어나게 됩니다. Component는 이 Action을 불러서 호출하죠.
그렇게되면 dispatch를 통해 이 Store에 전달 되는데요, bindListener를 통해 어떤 액션의 이벤트를 받을지 매핑할 수 있습니다.
이걸보면 어떤 Action이 이 Store에 관여하게 되는지 알 수 있죠.
이렇게 데이터를 저장하고, 변경하는 과정이 이 Store에서 일어납니다.
그리고 일반적인 React Component가 View 역할을 하죠. 이 때, 이 Component가 어떤 Store의 데이터를 받아서 그릴지
선택하게 되는데, Alt는 AltContainer라는 클래스로 이렇게 편하게 바인딩 해줄 수 있습니다. 이러면 이후부터 TodoStore가 변경될 때 자동으로 View는 렌더링을 하게 됩니다.
window.fetch 잠깐 설명하고, 왜 superagent를 선택하게 됐는지 말로 설명하고 넘어감.
이걸 우리는 prefetch 과정이라고 함
라이브러리 너무 많고, 너무 많이 변경된다고 불만을 토로…
가장 큰 문제가 페이지 트랜지션 이었음
가장 큰 문제가 페이지 트랜지션 이었음
이렇게 해놓고 Router에서 불렀던 Action 결과를 기다리지 않고 라우팅이 끝나게 처리하면 됨