프론트엔드 개발론¶
개요¶
웹 프론트엔드 기술은 빠르게 발전하고 변화하고 있습니다.
SPA 개발 프로젝트는 아래의 항목을 중점으로 개발 환경을 개선하고자 시작하였습니다.
성능(속도)
유지보수성
효율성
새로운 방식에서 많은 변화가 있는 만큼,
이를 제대로 활용하기 위해 필요한 내용을 문서로 작성하였습니다.
MPA(기존)과 SPA¶
SPA는 Activty 하나에 webview 내에서 hash(bookmark) 기준으로 화면을 제어합니다.
기존 Stack 관리방식이 아닌 history 관리를 통해 이루어져야 합니다.
화면 이동 프로세스
<기존 프로세스>
<SPA 프로세스>
화면 제어를 JS에 일임함으로써, 브라우저는 정적인 리소스자원을 최초 1회만 다운로드 받습니다.
화면이 변경되는 것에 대해서 최소한의 자원을 소모하므로 속도 향상을 기대할 수 있습니다.
또한, 화면이 새로고침 되지 않음으로 보다 나은 사용자 경험을 제공할 수 있습니다.
모듈화¶
기존 프로젝트에서는 mcore.extends.js에서 사용할 js파일을 선언하여
모든 화면에 대해서 해당 js파일이 <script>태그를 통해 inject되도록 사용해 왔습니다.
<기존 화면에 대한 리소스>
이러한 구조는 실제 화면에서 사용하지 않는 js파일을 불러오거나, 의존성 관계를 파악할 수 없기 때문에 복잡한 소스코드가 되기 쉬운 구조입니다.
모듈화(import/export)를 통해 이러한 문제점을 보완 할 수 있습니다.
Note
SPA 프로젝트에서는 기존 2버전대 호환과 라이브러리 업데이트 관리를 위해서 해당 mcore.extends.js를 삭제하지 않았으나 사용을 지양해주시길 바랍니다.
모듈화는 크게 두가지가 있습니다.
CommonJS와 ES6
CommonJS는 대표적으로 nodejs에서 사용되고 있습니다.
const module = require(‘module’);
SPA 프로젝트에서는 webpack 설정을 커스터마이징 하지 않는 이상 사용할 일이 거의 없습니다.
ES6는 브라우저에서 주로 사용되는 방식으로 SPA 프로젝트 내에서 ES6 사용을 권장합니다.
실제 브라우저에서 사용하기 위해서는
<script type=”module” src=”main.js”></script>
위와 같이 선언하여야 모듈을 사용할 수 있지만, webpack을 통해 이런 과정에 대해 생략이 가능합니다.
특징으로는 트리 셰이킹을 통해서 사용하지 않는 소스코드는 로드 하지 않습니다.
import 예제
import module from ‘module-name’;
아래의 링크를 통해서 export 및 import 활용 방법에 대해 확인하십시오.
개발 환경 변화¶
작업 영역
기존에는 HTML, CSS, JS을 그대로 사용하는 구조였으나,
Webpack을 사용함으로써 일련의 트랜스파일링을 통해 브라우저가 이해할 수 있는 리소스로 변환되어 web에 동작하게 됩니다.
소스 최적화(난독 및 압축)
모듈화
Dynamic Import (Lazy Load)
실제 작업 영업은 SPA 프로젝트에서 제공되는 frontend 폴더이며,
번들링된 소스는 asstes/res/www 에 생성됩니다.
(설정에 따라 변경될 수 있습니다)
ES6 사용
브라우저 버전 별 ES6에 대한 지원 유무가 다릅니다.
때문에 기존 프로젝트에서는 동작을 보장받을 수 없기 때문에 대부분 es5만 사용하는 것이 일반적으로 굳어 가고 있습니다.
SPA 프로젝트에서는 Babel을 통해서 사용하는 es6문법에 대한 동작이 보장되기 때문에 코드를 좀 더 심플하고 안정성 있도록 작성할 수 있습니다.
적어도, 아래의 목록에 대해서는 적극적으로 사용을 권장합니다.
Arrow Function (화살표 함수)
let 와 const (변수)
Template literals (문자열 선언 방식)
Method definitions (메소드 선언)
Destructuring assignment (구조분해할당)
Promise (비동기)
Default parameters (기본 파라미터)
Rest parameters (Rest 파라미터)
Spread syntax (전개 구문)
NPM (node package manager)
SPA 프로젝트는 기본적으로 nodejs 프로젝트의 형태로 제공됩니다.
기존 프로젝트에서는 외부 라이브러리를 다운로드 받아 lib 폴더를 생성하여 관리하였습니다.
하지만 nodejs 프로젝트에는 Gradle 또는 Maven과 비슷한 역할을 하는 npm이 있습니다.
자주 사용하는 moment, swiper, lodash, chartjs 등 많은 패키지를 npm을 통해 쉽게 설치 할 수 있습니다.
Note
package.json 파일에서 프로젝트 내 외부 Dependency을 확인할 수 있습니다.
해당 외부 라이브러리는 node_modules 폴더 내에 생성되게 됩니다.
아래의 링크에서 사용할 패키지를 검색하여 설치가 가능합니다.
컴포넌트 관점 개발¶
개요
기존 프로젝트에서는 페이지 단위 개발로 화면에 대해 하나씩 js파일이 대응 되었습니다.
UI개발에 있어서 과거에는 HTML, CSS, JS 각각에 대한 관심사의 분리가 당연하다고 생각했습니다.
하지만, 일반적으로 문제가 발생되었을 경우에는 HTML, CSS, JS가 함께 수정되는 부분이 많습니다.
이 때에는 분리된 환경보다 한 곳에서 관리하는 경우에 훨씬 수월해집니다.
이미 react, angular, vue 에서는 한 파일에서 관리할 수 있는 템플릿을 제공하고 있습니다.
컴포넌트
컴포넌트 란, 재사용이 가능한 최소 단위를 말합니다.
컴포넌트 접근법은 함수형 프로그래밍과 연관이 많습니다.
문제 없이 하나의 일을 잘 수행하는 함수
그러한 함수를 조합함으로 큰 문제를 해결
아래와 같은 특징을 가지고 있습니다.
한 파일에서 HTML, CSS, JS 관리
트러블 슈팅 및 변경에 따른 대처가 유연
State (상태)를 통해 UI를 조작
중복 소스 코드 최소화
SPA 프로젝트에 적용된 Vue 프레임워크 또한 위와 같은 사고로 접근하고 있기 때문에
적절하게 분리하지 않거나, 사용하지 않는다면 오히려 복잡해질 수 있습니다.
Note
적어도 컴포넌트 파일(.vue)은 200 라인을 넘지 않도록 작성하시는 것을 권장드립니다.
아래는 vue 컴포넌트 스타일 가이드에 대한 내용입니다.
https://vuejs-kr.github.io/jekyll/update/2017/03/13/vuejs-component-style-guide/
MVVM 패턴¶
JQuery나 DOM API는 ‘API를 통해 DOM을 제어한다’는 사고로 접근하고 있습니다.
이러한 접근방법은 아래와 같은 문제를 야기할 수 있습니다.
UI의 형태를 한눈에 파악하기 어려움
상태를 class 나 data-attr 관리하여 전체 흐름 파악이 어려움
DOM API 호출 비용이 비싸지만, 상태 변화를 위해 다량의 API 호출이 필요
이러한 구조에서는 쉽게 로직이 점점 커지고 복잡해지며, 이로 인해 유지보수가 매우 힘들어집니다.
Vue에서는 API를 통해 제어하는 방식이 아닌 ‘State(상태)만 제어’ 하는 사고로 접근합니다.
이 접근방법은 코드는 간결하고 심플하게 만들어줍니다.
Vue는 MVVM 패턴에 어느정도 영향을 받았다고 밝혔습니다.
MVVM패턴이란, 비즈니스 로직과 프레젠테이션 로직을 UI로부터 분리하기 위한 디자인 패턴입니다.
아래의 3가지 구성요소로 구성되어 있습니다.
항목 |
설명 |
비고 |
|---|---|---|
Model |
데이터 모델 |
|
View |
유저 인터페이스 |
|
View-Model |
뷰와 모델 사이 인터페이스 역할 상태 데이터가 변경되면 이를 감지하고 화면에 반영 |
이는 아래와 같이 동작합니다.
View 에서 액션 발생
View-Model에서 DOM Listeners가 액션 실행하여 Model 데이터 수정
수정된 Model 데이터를 View-Model이 View를 수정