2017년 12월 30일 토요일

GDG 정리

GDG fest 17/11/19 in Seoul UNI


Why Typescript with Clean Architecture

  • 발표자 장유진
  • banksalad 상품 -> 금융 솔루션이라 프로젝트의 사이즈가 커짐-> 관리가 어려움
    1. 제품관점

      제품의 궁극적인 모습을 상상해보면?
      같은 주제도 여러 관점에서 다룬다.
      * Microservice Acrhitecture :: 각 기능별로 서버를 구현


클라이언트는 다양한 기능이 모이는곳이라 중요함
2. 협업관점
같은 주제도 다르게 생각한다.
관점을 통일하지 않으면 문제가 생긴다.
3. 개발 환경 관점
JS의 근본적인 문제 오류 검출이 힘들다
* 해결방안 typesafe 언어 지식기반으로 만든다.
* 지식 중심의 명확한 아키택쳐
DDD(Domain Driven Design)
도메인 전문가와 엔지니어가 모델을 만들어서 아키택쳐를 만든다.
* 빠른 개발 속도

> 변경이 적은 코드

프론트엔드 프레임 워크 낱낱히 파해치기


react, Django 로 만드는 progressive web app

  • PWA 웹의 장점과 앱의 장점을 더한 개념
  • 어느 브라우저를 선택하든 상관없이 점진적 기능 개선을 통해 모든 사용자에게 제공
  • 반응형
  • 따로 앱을 만들지 않아도 앱아이콘 푸쉬 가능
  • 업데이트를 하지 않고 항상 최신화
  • service worker
  • mainjs 요청하면 서비스 워커가 가로 챈다-> 캐시를 확인하여 캐시가 있는지 확인 한다.->(네트워크 연결X )캐시에 있으면 화면 랜더링
  • 업데이트는 랜더링 다음에 한다.
  • 서비스 워커는 cra에 저장 되어있음
  • 파일명 해쉬도 cra가 해준다.
  • 브라우저 캐시 vs 서비스 워커
  • 브라우저 캐시는 일정 기간 마다 없어지는 경우가 있음 그리고 크기가 제한적(모든 사이트를 저장하기 때문에)

Redux 정리

REDUX


Redux의 특성

1. Single Source of Truth

어플리케이션의 state를 위해 단 한개의 store를 사용합니다.
Flux에서는 여러개의 store를 사용합니다.

2. State is Read-Only

어플리케이션에서는 store의 state를 직접 변경할 수 없습니다.
state를 변경하기 위해선 무조건 action이 dispatch 되어야합니다.

3. Changes are made with pure Function

action 객체를 처리하는 함수를 reducer라고 합니다.
reducer는 정보를 받아서 상태를 어떻게 업데이트 할 지 정의합니다.

reducer는 ‘순수함수’로 작성되어야합니다.

즉 네트워크 및 DB 접근 X, 인수 변경 X
같은 인수로 실행된 함수는 언제나 같은 결과를 반환
순수하지 않은 API 사용불가

>

구성요소

  • Action Creator

    어플리케이션 상태를 바꾸고 싶다면 항상 액션을 보내야 한다(무조건).
    무슨 메시지를 보낼지 알려주면 액션 생성자는 나머지 시스템이 이해할 수 있는 포맷으로 바꿔준다
    Flux와는 다르게 Redux의 액션 생성자는 디스패쳐(dispatcher)로 액션을 보내지는 않는다. 대신, 포맷을 바꾼 뒤 액션을 돌려준다.

  • Store

모든 상태 변화는 스토어에 의해서 이루어져야 하고 스토어로 직접 요청하는 대신 액션 파이프라인을 따라가야 한다.
Flux에서는 다수의 스토어를 가질 수 있지만 Redux에서는 한개의 Store만 가질 수 있다.
Redux의 스토어는 상태 트리(state tree) 전체를 유지하는 책임을 진다.
액션이 들어왔을 때 어떤 상태변화가 필요한지에 대한 일은 위임한다.
Flux의 디스패쳐의 역활도 한다.

  • Reducer

스토어는 액션이 어떤 상태 변화를 만드는지 알 필요가 있을 때 리듀서에게 묻는다.
이것이 바로 Redux의 키 아이디어 중 하나이다. 상태 객체는 직접 변경되지 않는다. 대신, 각각의 상태 조각이 복사 후 변경되고 새로운 상태 객체 하나로 합쳐진다.
리듀서는 복사되고 업데이트된 상태 객체를 루트 리듀서에게 넘겨주고, 루트 리듀서는 이 객체를 스토어로 보낸다. 그리고 스토어는 이 객체를 새로운 애플리케이션 상태로 만든다.

  • View

똑똑한 컴포넌트와 멍청한 컴포넌트

Smart Dumb
액션처리를 책임진다. 우직한 컴포넌트는 액션에 직접 의존성을 가지지는 않는다
똑똑한 컴포넌트는 props를 통해서 멍청한 컴포넌트에 함수를 보낸다 멍청한 컴포넌트는 받은 함수를 콜백으로써 단순히 호출만 한다
CSS style XX CSS style OO
DOM XX DOM OO

* View Layer Binding

스토어를 뷰에 연결하기 위해서 Redux는 약간의 도움이 필요하다. 그 둘을 함께 묶어줄 무언가가 필요한데, 이걸 해주는 것이 바로 뷰 레이어 바인딩이다

  1. 공급 컴포넌트(provider component): 컴포넌트 트리를 감싸는 컴포넌트이다. connect()를 이용해 루트 컴포넌트 밑의 컴포넌트들이 스토어에 연결되기 쉽게 만들어준다.
  2. connect(): react-redux가 제공하는 함수이다. 컴포넌트가 애플리케이션 상태 업데이트를 받고 싶으면 connect()를 이용해서 컴포넌트를 감싸주면 된다. 그러면 connect()가 셀렉터(select)를 이용해서 필요한 모든 연결을 만들어준다.
  3. 셀렉터(selector): 직접 만들어야 하는 함수이다. 애플리케이션 상태 안의 어느 부분이 컴포넌트에 props로써 필요한 것인지 지정한다.

    • Root Component

모든 React 애플리케이션은 루트 컴포넌트를 가진다. 이것은 단지 컴포넌트 계층 구조에서 가장 위에 위치하는 컴포넌트일 뿐이다. 하지만 Redux에서는 루트 컴포넌트는 추가로 책임져야 할 것이 존재한다.
하지만 루트 컴포넌트는 애플리케이션을 초기화한 뒤로는 거의 하는 일이 없다. 화면을 갱신도 더는 신경 쓰지 않는다. 화면 갱신은 뷰 레이어 바인딩의 도움으로 아래의 컴포넌트들이 맡아서 처리한다.


SetUp

  1. Ready Store
  2. Prepare communication between store and component
  3. Ready Action Callback

DataFlow

  1. 뷰가 액션을 요청한다. 액션 생성자가 포맷을 변환한 뒤 돌려준다
  2. bindActionCreators()가 준비과정에서 사용되었으면 자동으로 액션이 보내진다. 그게 아니라면 뷰가 직접 액션을 보낸다
  3. 스토어가 액션을 받는다. 현재 애플리케이션 상태 트리와 액션을 루트 리듀서에게 보낸다.
  4. 루트 리듀서는 상태 트리를 조각으로 나눈 뒤 알맞은 서브 리듀서로 상태 조각들을 넘겨준다.
  5. 서브 리듀서는 받은 상태 조각을 복사한 뒤, 그 복사본을 변경한다. 루트 리듀서에게 변경된 복사본을 돌려준다.
  6. 모든 서브 리듀서가 변경 된 상태 조각들을 돌려주면, 루트 리듀서는 이 상태 조각들을 한데 모아 상태 트리로 만든 뒤 스토어로 돌려준다. 스토어는 새로운 상태 트리를 옛날 상태 트리와 바꾼다.
  7. 스토어는 뷰 레이어 바인딩에게 애플리케이션 상태가 변경되었다는 것을 알린다.
  8. 뷰 레이어 바인딩은 스토어에게 새로운 상태를 보내달라고 요청한다.
  9. 뷰 레이어 바인딩은 뷰에게 화면을 업데이트하도록 요청한다.

Typescript Meetup

Typescript Korea MeetUp 2018 2018년 1월 18일 강남 마루180 19:00 ~ 21:10 Typescript 로 부터 얻은것과 잃은 것 발표자 손찬욱 (네이버) eg.js 개발중 Typescript 사용기 eg...