[Vue] Vue.js 완벽 가이드

슬지로운 개발생활·2021년 10월 27일
1

Vue

목록 보기
2/2

입사한 이후 Vue를 따로 배울새 없이 들어가서 기초가 부족하다 판단되어,
인프런 Vue.js 완벽 가이드 - 실습과 리팩토링으로 배우는 실전 개념 배운 뷰 개념 정리
Github페이지는 여기로~!

Vue CLI 2.X vs Vue CLI 3.X

  1. 명령어

    • 2.X : vue init '프로젝트 템플릿 이름' '파일 위치'
    • 3.X : vue create '프로젝트 이름'
  2. 웹팩 설정 파일

    • 2.X : 노출 O
    • 3.X : 노출 X
  3. 프로젝트 구성

    • 2.X : 깃헙의 템플릿 다운로드
    • 3.X : 플러그인 기반으로 기능 추가
  4. ES6 이해도

    • 2.X : 필요 X
    • 3.X : 필요 O

현재 공홈에선 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
    • API호출해서 데이터만 가져온다.

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:myEventv-on:myevent로 변환된다.

비 부모-자식간 통신(Event Bus)

  • 부모자식 컴포넌트가 아닌데 통신 할 필요가 있는경우, 사용한다.
  • bus같은 경우 라이프 사이클 훅 부분에 정의한다.

HOC

  • react의 High Order Components에서 기원되었다.
  • 하이 오더 컴포넌트는 컴포넌트의 로직(코드)을 재사용하기 위한 고급 기술이다.
  • 페이지 컴포넌트를 재활용했다고 보는게 더 맞다.
  • 단점: 컴포넌트 레벨이 깊어진다.(통신하기 까다로워진다)
    • HOC를 많이 쓸수록 컴포넌트의 깊이가 깊어져
      컴포넌트 통신간의 불편한 현상들이 발생
  • ex) 코드의 반복성을 줄이기 위해 계속 반복되는 컴포넌트를 여러개 두지 않고, 한개로 만들어서 관리

Mixin

  • 여러 컴포넌트 간에 공통으로 사용하고 있는 로직, 기능들을 재사용하는 방법
  • mixin에 정의할 수 있는 재사용 로직은 data, methods, created 등과 같은 컴포넌트 옵션이다.
    1. 컴포넌트의 코드들이 정리가 된다.
    1. 부차적인 요소들(스피너, 모달 끄고 닫는 것 등)을 믹스인으로 뺄때 효율이 좋다.
    • 컴포넌트의 로직들이 단순해지면서 CRUD에 관련된 비즈니스 로직만 남게된다.
    • 부차적인 도구의 로직들을 전부다 믹스인으로 뺄 수 있고,
      때에 따라선 CRUD도 어느정도 공통 컴포넌트화가 가능하다.
  • mixin 파일 이름은 자세할수록 좋다!
  • 단점: 믹스인을 여러개 주입했을때 특정 코드가 어느 믹스인에서 주입된건지 확인하기 어렵다.
  • ex) 따로 관리하는 사이드 로직들을 걷어내고, 컴포넌트에 비즈니스 로직만 남겨 구분하는 용도로 사용

컴포지션 API가 필요한 이유

데이터 호출 시점

  1. 라우터 네비게이션 가드 (컴포넌트 진입전 라우터에서)
    • 특정 URL로 접근하기 전의 동작을 정의하는 속성(함수)
    • 컴포넌트 생성 전 라우팅 상태에서 데이터 호출 가능
    • UX가 화면상으로는 데이터가 받아온 시점에서 그려지기 때문에 깔끔한 화면이 될 수 있지만,
      사용자가 기다리게끔 인지할 수 있는 UI 컴포넌트 필요(ex.spinner)
  2. 컴포넌트 라이프 사이클 훅
    • created : 컴포넌트가 생성되자 마자 호출되는 로직
    • 컴포넌트 생성 후 호출
  • 어느 시점에 데이터를 호출할지 선택권이 생긴다.
    라우터 네비게이션 가드가 컴포넌트 라이프 사이클 훅에서 호출한것보다 더 먼저 호출된다.
  • 사용자가 기다려도 되니 데이터를 다 가져오고 난 뒤에 뿌리는 방법과
    일단 페이지 전환해 아무거나 뿌리고 데이터가 들어오면 추가적으로 뿌리는 방법,
    2가지가 있으니 때에 맞춰 잘 사용할 것!

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

0개의 댓글