입사한 이후 Vue를 따로 배울새 없이 들어가서 기초가 부족하다 판단되어,
인프런 Vue.js 완벽 가이드 - 실습과 리팩토링으로 배우는 실전 개념
배운 뷰 개념 정리
Github페이지는 여기로~!
Vue CLI 2.X vs Vue CLI 3.X
-
명령어
- 2.X : vue init '프로젝트 템플릿 이름' '파일 위치'
- 3.X : vue create '프로젝트 이름'
-
웹팩 설정 파일
-
프로젝트 구성
- 2.X : 깃헙의 템플릿 다운로드
- 3.X : 플러그인 기반으로 기능 추가
-
ES6 이해도
현재 공홈에선 Vue CLI 2.X(vue init ~)은 레거시에 포함시켰다.
https://cli.vuejs.org/guide/creating-a-project.html#pulling-2-x-templates-legacy
Vuex
상태관리 도구다.
주요 속성
- state: data
- getters: computed
- mutation: methods
- actions: 비동기 methods
v-html
Slot
구멍이라는 뜻처럼 특정 컴포넌트에 등록한 하위 컴포넌트의 마크업을 확장하거나 재정의할 수 있다.
- react 할때 쓴적이 없어서 이해하는데 애먹음
- react에선 props.children으로 해서 쓸 수 있다.
→ 예전에 써본적 있는거같은데 뇌피셜인가..
참고 :
코드 연습:
Template
- 뷰의 템플릿은 html, css등의 마크업 속성과 뷰 인스턴스에서 정의한 데이터 및 로직들을 연결하여 사용자가 브라우저에서 볼 수 있는 형태의 html로 변환해주는 속성이다.
- template 태그는 화면에 그려질 때 HTML 태그가 없다.
- 리액트의 fragments와 비슷하다.(완전 똑같지 않다)
- fragment: Fragments는 DOM에 별도의 노드를 추가하지 않고 여러 자식을 그룹화
- template: 템플릿은 마운트 된 엘리먼트를 대체
Event
- component / props와 달리 이벤트는 자동 대소문자 변환을 제공하지 않기 때문에,
emit할 정확한 이벤트 이름을 작성하는 것이 권장된다.
this.$emit('myEvent')
<!-- event 동작 안함 -->
<my-component v-on:my-event="doSomething"></my-component>
- DOM 템플릿의 이벤트 리스너는 항상 자동으로 소문자 변환되기 때문에,
이벤트 이름에는 Kebab-case를 사용하는 것이 권장된다.
v-on:myEvent
는 v-on:myevent
로 변환된다.
비 부모-자식간 통신(Event Bus)
- 부모자식 컴포넌트가 아닌데 통신 할 필요가 있는경우, 사용한다.
- bus같은 경우 라이프 사이클 훅 부분에 정의한다.
- react의 High Order Components에서 기원되었다.
- 하이 오더 컴포넌트는 컴포넌트의 로직(코드)을 재사용하기 위한 고급 기술이다.
- 페이지 컴포넌트를 재활용했다고 보는게 더 맞다.
- 단점: 컴포넌트 레벨이 깊어진다.(통신하기 까다로워진다)
- HOC를 많이 쓸수록 컴포넌트의 깊이가 깊어져
컴포넌트 통신간의 불편한 현상들이 발생
- ex) 코드의 반복성을 줄이기 위해 계속 반복되는 컴포넌트를 여러개 두지 않고, 한개로 만들어서 관리
Mixin
- 여러 컴포넌트 간에 공통으로 사용하고 있는 로직, 기능들을 재사용하는 방법
- mixin에 정의할 수 있는 재사용 로직은 data, methods, created 등과 같은 컴포넌트 옵션이다.
- 컴포넌트의 코드들이 정리가 된다.
- 부차적인 요소들(스피너, 모달 끄고 닫는 것 등)을 믹스인으로 뺄때 효율이 좋다.
- 컴포넌트의 로직들이 단순해지면서 CRUD에 관련된 비즈니스 로직만 남게된다.
- 부차적인 도구의 로직들을 전부다 믹스인으로 뺄 수 있고,
때에 따라선 CRUD도 어느정도 공통 컴포넌트화가 가능하다.
- mixin 파일 이름은 자세할수록 좋다!
- 단점: 믹스인을 여러개 주입했을때 특정 코드가 어느 믹스인에서 주입된건지 확인하기 어렵다.
- ex) 따로 관리하는 사이드 로직들을 걷어내고, 컴포넌트에 비즈니스 로직만 남겨 구분하는 용도로 사용
데이터 호출 시점
- 라우터 네비게이션 가드 (컴포넌트 진입전 라우터에서)
- 특정 URL로 접근하기 전의 동작을 정의하는 속성(함수)
- 컴포넌트 생성 전 라우팅 상태에서 데이터 호출 가능
- UX가 화면상으로는 데이터가 받아온 시점에서 그려지기 때문에 깔끔한 화면이 될 수 있지만,
사용자가 기다리게끔 인지할 수 있는 UI 컴포넌트 필요(ex.spinner)
- 컴포넌트 라이프 사이클 훅
- created : 컴포넌트가 생성되자 마자 호출되는 로직
- 컴포넌트 생성 후 호출
- 어느 시점에 데이터를 호출할지 선택권이 생긴다.
라우터 네비게이션 가드가 컴포넌트 라이프 사이클 훅에서 호출한것보다 더 먼저 호출된다.
- 사용자가 기다려도 되니 데이터를 다 가져오고 난 뒤에 뿌리는 방법과
일단 페이지 전환해 아무거나 뿌리고 데이터가 들어오면 추가적으로 뿌리는 방법,
2가지가 있으니 때에 맞춰 잘 사용할 것!
Navigation Guard
beforeEnter
- to: 이동하려는 페이지(이동할 위치의 라우팅 정보)
- from: 현재 페이지(현재 위치의 라우팅 정보)
- next: 함수, beforeEnter에서는 무조건
next()
를 호출해줘야지만 해당 url로 이동 가능
비동기
.then()
&.catch()
- Promise를 쓸 땐
then&catch
- 네트워크 요청 혹은 비동기 요청에 대해서만 예외 처리를 한다.
try
&catch
- 비동기처리 요청뿐만 아니라 일반적인 자바스크립트 코드 에러까지 예외 처리를 한다.
(좀더 포괄적)
- async를 쓸때
try&catch
- Tip: 공통적으로 발생하는 에러케이스에 대해서는 (예. handleException이라는)공통함수를 만들어 처리할 수 있다.
외부 라이브러리 모듈화
- 이유: Vue.js 관련 라이브러리가 없을 때 일반 라이브러리를 결합할 수 있어야 함
- 종류
1) 차트
2) 데이트 피커
3) 테이블
4) 스피너
컴포넌트 디자인 패턴
Common
기본적인 컴포넌트 등록과 컴포넌트 통신 방식
- 기본적으로 뷰에서 추구하는 one way data flow라던지,
컴포넌트간의 다대다 data통신방식을 하게 되면 나중에 컨트롤 하기 어렵기 때문에
일반적인 패턴으로 구조화를 하게 된다.
- 내려준 데이터를 가지고 표현하거나, 조절하게되면 다시 이벤트로 올리게 되는 기본적인 컴포넌트 설계방식
- Container Component(컨테이너 컴포넌트):
- presentational컴포넌트들과 container컴포넌트들을 관리하는것을 담당한다.
- Presentational Component(프레젠테이셔널 컴포넌트):
- 컨테이너 컴포넌트 하위에 있는 / 말단에 있는(end단에 있는) 컴포넌트
- 뷰(view)만을 담당하는 컴포넌트
- 참고 : Presentational 컴포넌트와 Container 컴포넌트
Slot
마크업 확장이 가능한 컴포넌트 설계 방식
- Slot vs Props
- 데이터를 내려준 하위 컴포넌트에 대한 의존성이 없어진다.
→ 데이터는 아직도 상위 컴포넌트에만 머물러있기 때문이다.
→ 하위 컴포넌트에서 상위 컴포넌트의 내용을 표현만 했다.
→ props로 내렸을 경우 하위 컴포넌트에서 수정할 수 없는 제약사항이 생긴다.
- slot태그가 사라지면서 상위에서 정의한 내용이 들어간다.
- slot은 유연하게 화면을 확장할 수 있다.
- Ex) 리스트중에 하나는 다르게 표현 하고 싶을때
<Item>
아이템 1
</Item>
<Item>
아이템 2
<button> click me!</button>
</Item>
- 쇼핑몰 detail 상품, 모달 같은것을 마음대로 확장할 수 있다.
- 정의하는 곳(상위 컴포넌트)에서 돔구조와 스타일을 줄 수 있다.
Controlled
결합력이 높은 컴포넌트
- 하위 컴포넌트와 상위 컴포넌트가 밀착된 형태로 컴포넌트를 구현
- 서드파티 라이브러리들/체크박스를 컨트롤 할 때 쉽게 컨트롤 할 수 있게 설계할 수 있다.
v-model
- @input(이벤트) : 이벤트로 날리고~
- :value(값) : 받을때는 value로 받고~
- 상위 컴포넌트에서 데이터를 관리하게 된다.
- 컴포넌트의 데이터 의존성을 분리한것 → 디자인패턴의 핵심
- 결합력 높은 컴포넌트를 만들 수 있다.
- Ex) 캘린더, 모달, 입력폼등 세부적인 컴포넌트를 쪼갤때 유용한 방식이다.
Renderless
데이터 처리 컴포넌트
- 데이터를 처리하는 컴포넌트로 템플릿 표현식이 없다. → script만 있다.
- 표현을 하지 않는 컴포넌트
- 데이터 제공하는 컴포넌트(data provider)
- 스크립트 단에서 비즈니스 로직만 처리, 상위 컴포넌트로 다시 데이터 노출하는 컴포넌트
Props Validation
props 일반적인 선언방식: 배열
props가 컴포넌트간의 주고받는 데이터이다 보니
validation(유효성)검사가 필요해서 type, require, 기본값등을 설정할 수 있다.
Deploy
build
- 명령어 :
npm run build
- 상용 서비스를 위해 파일을 빌드한다.
- 빌드한 후 dist폴더가 생성된다.
- 정적인 웹 자원(file)들이 들어있다.(html, css, js 등)
→ 이대로 웹 서버에 올리면 된다.
- dist폴더 밑에 호스팅할 수 있는 파일들이 생성된다.
- 내부적으로 웹팩이 다 돈다.
env file
- 코드를 제작하고 서버에 배포할때, 특정 옵션들을 바꾸고 싶을때 이런 옵션들을 담아놓는 파일
- 브라우저에 어떤값을 노출하고 싶지 않을 때 env파일에 담아서 몰래 관리하는 방법도 있다.
API Mock Data