Vue Family Bucket 실제 프로젝트 요약 공유 예시-JS 튜토리얼-php.cn

프런트엔드 관점에서 볼 때 Vue는 현재 가장 이상적인 프런트엔드 MVVM 프레임워크라고 할 수 있습니다. 이 기사에서는 Vue 제품군 버킷(Vue)의 사용을 기록합니다. +Vue-router+Vuex)를 통해 jQuery+를 재구성합니다. 템플릿 프로젝트의 과정과 해당 기간 동안의 이익. 이번 글은 주로 Vue 패밀리 버킷 실용 프로젝트 요약(권장)을 소개합니다. 편집자께서 꽤 괜찮다고 생각하셔서 지금 공유하고 참고용으로 올려드리겠습니다. 편집자를 따라 살펴보겠습니다. 모두에게 도움이 되기를 바랍니다.

Getting Started

Vue 공식 문서는 Vue 학습을 위한 최고의 튜토리얼입니다. 아마도 프레임워크 작성자가 디자이너이고 백엔드 배경 지식이 없기 때문에 다양한 추상 개념을 사용할 수 있기 때문일 것입니다. Vue에서 가장 이해하기 쉽게 설명되어 있습니다. 여기서는 Vue, Vue-router 및 Vuex의 개념만 간략하게 소개합니다.

Vue

Vue의 핵심 기능은 양방향 바인딩으로, 인터페이스 중심 데이터 변경과 데이터 중심 인터페이스 변경을 자동으로 실현할 수 있어 프런트 엔드가 풍부한 대화형 애플리케이션의 개발 비용을 크게 줄일 수 있습니다. Vue와 같은 유사한 프레임워크가 두 개 이상 있지만 Vue를 구현하면 ES5의 기본 기능을 활용하여 성능 면에서 특정 이점이 있습니다.

Vue-router

Vue-router는 URL과 구성 요소 간의 매핑 관계를 구성하고 구성 요소에 대한 URL 변경에 자동으로 응답하는 데 사용되는 공식 경로이므로 개발자는 구성 요소에만 집중하면 됩니다. 개발 과정에서 라우팅은 관련된 사소한 문제를 해결하는 데 도움이 됩니다.

Vuex

Vuex는 복잡한 데이터 흐름 상황을 처리하기 위해 중앙 집중식 데이터 관리 모델을 제공합니다. 예를 들어 여러 구성 요소가 데이터를 공유하지만 독립적으로 작동하므로 동기화된 데이터가 동기화되지 않거나 js로 인해 발생할 수 있습니다. Object 객체의 Hook은 메모리의 동일한 인스턴스를 가리키므로 원본 데이터가 조작되면 다른 구성 요소가 오염됩니다. 이때 보다 체계적인 데이터 작업 모드가 필요합니다. 바로 Vuex입니다.

기술 선택

jQuery와 비교

Vue의 기본 개념을 이해한 후에는 무의식적으로 이러한 것들이 내 비즈니스에 적합한지 확실히 알고 싶습니다. 필요합니다.

먼저 MVVM으로 해결했던 문제를 jQuery로 해결할 수 있을까요? 대답은 '예'입니다. 양식을 제출할 때 jQuery를 사용하여 입력 값을 하나씩 가져오는 것을 기억하시나요? 이는 인터페이스 기반 데이터입니다. 비동기식 대화형 기능을 수행한 경우 jQuery를 사용하여 인터페이스의 다양한 요소에 Ajax 데이터를 채운 경험이 있어야 합니다. 가능하긴 하지만 좀 번거롭긴 하지만, 양식 검증 플러그인과 프런트엔드 템플릿 엔진을 사용하더라도 여전히 실행 중인 각 노드에서 검증 방법과 렌더링 방법을 수동으로 호출해야 하므로 괜찮습니다. 웹사이트 페이지를 만들려고 하는데, 요구사항이 어느 정도 복잡할 경우에는 큰 부담이 됩니다.

라우팅의 본질은 URL을 작동하여 인터페이스를 유지 관리하는 것입니다. 이는 실제로 라우팅 요구 사항이 생성되는 한 관련이 없습니다. , jQuery를 기반으로 한 프로젝트도 단지 재창조일 뿐이지만 jQuery 시대에는 단일 페이지 애플리케이션이 거의 만들어지지 않습니다.

Vuex는 양방향 바인딩을 기반으로 완전히 확장됩니다. 이는 데이터와 구성 요소 사이에 브로커를 추가하는 것과 같습니다. 구성 요소는 데이터를 직접 작동할 수 없고 작업 요구 사항을 브로커에 제출할 수만 있으며 브로커는 이를 구현합니다. 이렇게 하면 너무 많은 사람과 많은 손으로 인해 발생하는 예측할 수 없는 다양한 문제가 해결되고, 데이터가 애플리케이션 외부로 이동되고 특별히 저장소가 구축되므로 구성 요소 간의 데이터 오염 문제가 제거됩니다. jQuery는 완전히 수동으로 데이터를 조작하고 예상치 못한 상황이 전혀 발생하지 않기 때문에 jQuery에는 이러한 요구가 없다고 해야 합니다.

적용 가능한 시나리오

jQuery와 비교해 보면 Vue의 적용 가능한 시나리오는 개발 관점에서 볼 때 더 복잡한 상호 작용이 있는 프로젝트가 더 적합하고 콘텐츠 웹 사이트가 가장 적합하지 않습니다. 웹사이트의 경우 필요한 경우 장바구니 페이지와 같은 개별 페이지에서 로컬로 사용할 수도 있습니다.

물론, 이 모든 것은 IE8과 호환되지 않는다는 전제에 기초해야 합니다. Vue를 사용하는 일부 2C 사이트를 본 적이 있기 때문에 나는 이것에 대해 약간 혼란스럽습니다.

프로젝트 분석

프로젝트 배경

이번 리팩토링 프로젝트는 이전 회사에서 개발한 프론트엔드 컴포넌트 관리 시스템의 요구 사항을 잘 알고 있기 때문에 이 프로젝트를 리팩토링하기로 했습니다. 일반적인 단일 프로젝트로, 중간 수준의 복잡성을 지닌 페이지 애플리케이션으로 실습에 더 적합합니다.

아웃소싱 웹 사이트 구축 회사에서는 디자인 과정에서 재사용 가능한 많은 구성 요소가 축적되어 디자이너가 구성 요소를 미세 조정하여 페이지를 구성하고 프런트 엔드에 전달하는 경우가 많습니다. 이론적으로는 이러한 구성 요소를 프런트 엔드에서도 재사용할 수 있지만 실제로는 프런트 엔드로 이동할 때마다 전체 페이지를 다시 구현해야 하므로 많은 인력이 낭비됩니다.

기능 요구사항

이 프로젝트의 아이디어는 모든 구성요소를 개발하고 이를 통합된 플랫폼에 입력하여 관리하는 것입니다. 디자이너는 플랫폼으로 가서 구성요소를 선택하고 실시간으로 구성요소를 미리 보고 조정할 수 있습니다. 전체 프로세스 중에 얻을 수 있으며 플랫폼은 조정 결과를 생성합니다. 코드가 프런트 엔드에 전달되는 한 이 코드 문자열을 사용하여 디자이너가 수정한 구성 요소를 재현할 수 있습니다. 플랫폼에 추가하고, 한 번의 클릭으로 컴포넌트의 html/css/js 코드를 복사해 프로젝트에 빠르게 적용할 수 있어 컴포넌트 부분의 프론트엔드 개발 비용을 거의 0에 가깝게 만들 수 있습니다. 플랫폼은 다음 기능을 구현해야 합니다.

구성 요소 관리, 분류 지원, 검색, 정렬
구성 요소 표시, 구성 요소 온라인 미리 보기/편집 지원
구성 요소 핸드오버, 구성 요소 코드 및 코드 생성 지원 기반 재생산 구성 요소 사용 통계
구성 요소의 추가 최적화를 촉진하기 위해 통계 구성 요소 사용을 지원합니다.

기능 분석

첫 번째 버전은 jQuery+템플릿을 사용하여 구현되었습니다. 장점은 무엇이든 하기 쉽지만, 어떻게 하든 상관이 없다는 단점이 있고, 아이디어를 명확하게 하는 데 도움이 되지 않고, 하다 보면 변화가 생기는 경우가 많습니다.

구성 요소는 구성 요소 라이브러리라고 하는 widgets/ 폴더에 배치됩니다. 이는 파일 작업 기능이 없는 순수 프런트 엔드 프로젝트이기 때문에 구성 요소 읽기는 정적 json 파일의 디렉터리 역할을 합니다. 컴포넌트 분류, 라벨, 이름, 날짜 등과 같은 모든 정보를 포함하는 데이터 구조는 대략 다음과 같습니다.

[{
 "title": "导航类",
 "list": [{
 "widget": "bread-1",
 "title": "图标面包屑",
 "tag": "面包屑/图标",
 "author": "UI",
 "date": "2015-06-04"
 }, 
 ...]
},
...]

로그인 후 복사

컴포넌트는 열/번호 형식으로 컴포넌트 라이브러리에 저장됩니다. 보조 폴더이며 저장 디렉터리를 구성 요소 코드로 사용하는 데 동의합니다. 예를 들어 구성 요소 bread-1은 이 구성 요소의 저장 주소가 widgets/bread/1/ 폴더임을 의미합니다.

물론, 구성 요소의 내부 파일 구조도 다음과 같이 합의되어야 합니다.

widgets
  |-bread
    |-1
      |-album.jpg   //缩略图
      |-config.json  //配置文件
      |-script.js   //脚本模板
      |-style.css   //样式模板
      `-temp.htm   //界面模板

로그인 후 복사

이러한 합의를 통해 프로그램은 디렉토리 파일을 통해 모든 구성 요소의 정보를 얻을 수 있으며 획득, 표시, 구성요소 검색도 실현될 수 있습니다.

구성 요소에서 가장 중요한 것은 구성 요소의 구성 가능한 항목과 기본값이 포함된 config.json 파일입니다. 플랫폼은 구성 요소를 표시할 때 이 구성 파일을 읽고 구성 정보를 기반으로 구성 패널을 생성합니다. 여기에서 정의할 수 있습니다. 구성 요소 인터페이스, 스타일 및 스크립트의 모든 변수에 대해 구성 파일은 다음과 같습니다.

{
 "cssConfig": {
 "fontSize": {
  "name": "字号",
  "value": "12px",
  "type": "text"
 },
 ...
 },
 "jsConfig": {
    ...
 },
 "showConfig": {
 "viewWidth": {
  "name": "栅格宽度",
  "value": 12,
  "type": "number"
 },
 ...
 }
}

로그인 후 복사

구성 파일에 있는 cssConfig, showConfig 및 jsConfig의 세 가지 분기는 컬렉션입니다. 이러한 변수를 결합하려면 컴포넌트에 적용할 때 프런트엔드 템플릿 엔진을 사용해야 하므로 개발 중에 컴포넌트의 세 가지 주요 부분이 템플릿 구문으로 작성됩니다. 템플릿 엔진으로 구문 분석한 후 스타일과 같은 실제 구성된 html/css/js 콘텐츠를 얻을 수 있습니다. 템플릿은 아마도 다음과 같습니다.

.widget-bread-1 {
  font-size: ${fontSize.value}; 
  color: ${textColor.value}; 
}
.widget-bread-1 a { 
  color: ${textColor.value};
}
.widget-bread-1 a:hover{
  color:${hoverColor.value};
}
.widget-bread-1 .ion { 
  font-size: ${iconSize.value}; 
  margin: 0 ${iconMargin.value};
}

로그인 후 복사

구성 요소의 실제 코드를 얻은 후 결과를 삽입하기만 하면 됩니다. HTML과 CSS는 텍스트 콘텐츠를 직접 대체할 수 있습니다. js는 모듈 방식으로 도입되므로 모듈 콘텐츠만 교체하면 모듈 전체가 오버로드되지 않습니다. 이므로 js 모듈의 이름은 무작위입니다.

여기서 문제가 발생합니다. 일부 구성 요소는 페이지에서 여러 번 사용해야 하므로 이 구성 요소의 js 선택기가 충돌합니다. 이 문제는 js 모듈의 임의 이름을 사용하여 해결할 수 있습니다. ID는 예약된 변수로 사용되며 플랫폼은 자동으로 임의의 문자열을 할당합니다. 이 문자열은 구성 요소 인스턴스 내에서 동일하지만 이러한 방식으로 여러 번 호출되면 달라집니다. ${id}는 구성 요소의 상위 노드의 ID 또는 클래스로 사용되므로 발생할 수 있는 CSS 이름 충돌 문제를 해결하기 위해 구성 요소의 CSS 네임스페이스로 사용할 수도 있습니다.

위 내용은 프로젝트의 핵심 기능입니다.

또한, localStorage는 현재 브라우저의 구성요소 사용 기록과 각 사용의 구성을 수집할 수 있는 독립형 데이터 통계를 구현하기 위한 저장 방법으로 사용됩니다. 이는 주로 로컬 저장소의 작동이지만, 프로젝트 자체의 프런트 엔드 템플릿과 함께 첫 번째 로드 후 localStorage를 사용하여 캐시되는 구성 요소 템플릿도 사용됩니다. 이러한 콘텐츠에 대한 캐싱 전략은 영구적으로 저장되어야 하며 프로젝트 템플릿은 수동으로 업데이트되어야 합니다. 상황에 따라 컴포넌트 템플릿을 업데이트해야 하며, 저장된 컨텐츠가 많은 경우 정리가 필요하므로 정리 중에 하나씩 삭제하면 실수로 손상될 수 있습니다. 여기서 접근 방식은 localStorage 작업을 캡슐화하는 것이며 저장 방법은 키 앞에 추가됩니다. 삭제 시 로컬에 저장된 키를 탐색하여 일치하는지 확인하면 됩니다. 해당 값 검색 방법은 값을 검색하기 전에 키에 대한 접두사를 반대로 바꿔야 합니다.

또한, localStorage는 객체 유형에 대한 액세스를 용이하게 하기 위해 문자열 액세스만 지원합니다. 그러나 이 변환은 객체가 일치할 때 문자를 맹목적으로 변환할 수 없습니다. 개체는 자동으로 개체로 변환되는데, 사용자가 개체 문자열을 실제로 저장한 후 꺼낼 때 그대로 가져오고 싶을 수 있기 때문입니다. 저장 방법은 값이 객체임을 감지하면 문자열로 변환된 다음 식별 문자열이 앞에 표시됩니다. 값 방법은 이 식별을 감지한 후에만 다음 문자열을 객체에 복원합니다. 이 접두사는 고정되어 있기 때문에 이론적으로 이 문제에 대한 다른 더 나은 해결책이 있는지는 모르겠습니다.

프로젝트의 주요 기능 포인트는 다음과 같습니다.

Refactoring

One refactoring

첫 번째 리팩토링은 Vue만 사용했습니다. 리팩토링 과정에서 가장 먼저 깨달은 것은 원래 템플릿 엔진을 호출해야 했던 작업이 프레임워크에 의해 수행되었다는 것입니다. 이제 원래 js에 바인딩된 이벤트는 이제 다양한 기타 구문 설탕과 함께 템플릿에 직접 바인딩될 수 있습니다.

물론 가장 중요한 것은 양방향 바인딩을 기반으로 인터페이스와 데이터가 자동으로 연결될 수 있으므로 사람들이 프로그램에 어느 정도 자율성이 있다고 느끼게 됩니다. 정상적으로 작동하려면 개발자는 모든 단계를 미리 계획해야 합니다. 이는 jQuery보다 덜 자유로워 보일 것입니다. 움직이는 벽돌을 예로 들면, jQuery는 벽돌을 쉽게 들어 올리고 멋진 방식으로 이동할 수 있는 특히 유연한 크레인과 같습니다. Vue는 벽돌을 특정 장소에서 다른 곳으로 옮기고 싶다고 말합니다. 특정 장소에서 일어나는 일은 어떻게 처리하느냐에 따라 달라지며, 버튼을 누르면 벽돌이 자동으로 이동할 수 있습니다.

두 방법 모두 장점과 단점이 있습니다. 크레인을 잘 운전하면 매우 유연할 수 있으며 도로의 구덩이를 피하기가 쉽습니다. 단점은 몇 번이고 운전해야 한다는 것입니다. 버튼은 자동으로 한 번만 실행되도록 프로그래밍할 수 있지만, 도로의 움푹 들어간 곳을 꼭 확인하고, 다른 모든 차량의 일정을 잡고, 모든 상황을 명확하게 설명해야 한다는 단점이 있습니다. 그렇지 않으면 차량이 전복되거나 충돌할 수 있습니다. jQuery에서 Vue로 전환하면 "행동하기 전에 계획을 세워라" "차에 탄 후에는 말할 수 없다"는 구속감을 확실히 느낄 것입니다.

재구축 기간 동안 작업의 큰 부분은 Vue 인스턴스를 구축하고, js 구석구석에 흩어져 있는 데이터를 데이터로 수집하고, 데이터를 비트 단위로 연산하는 과정을 메소드로 집중하고, 데이터 필터링 프로세스를 중앙 집중화하는 것입니다. 이 전체 과정은 모든 구현 세부 사항을 명확하게 검토하고 각 구현 방법이 합리적인지 여부를 반영할 수 있습니다. 실제로 모든 요약이 완료되면 원격 제어 버튼으로 크레인을 구동하는 원래 프로세스를 요약할 수 있습니다. Vue 예제는 최종 프로젝트가 되며 자동으로 실행될 수 있습니다.

재구축 후 Vue의 다양한 기능에 의존하여 논리적 부분의 코드 양을 줄였습니다. 이 외에도 라우팅이 없기 때문에 새로 고침 상태가 손실되는 문제가 있습니다. 페이지가 여전히 존재합니다. Vuex는 데이터 오염 구덩이에 직면했는데, 이는 깊은 복사로만 해결될 수 있었고 구성 요소 기반 개발 모델로 인해 코드 구성이 더욱 단편화되었습니다.

2차 재구성

2차 재구성의 목표는 라우팅, Vuex, 코드 구성 및 Wild Dog Cloud 백엔드를 개선하는 것입니다.

첫 번째 리팩토링을 경험했지만 두 번째 리팩토링을 시작할 때 라우팅과 Vuex 중 어느 것을 먼저 구현해야 할지 아직도 조금 혼란스럽습니다. 생각해보면 라우팅이 하는 일은 '해체'이고, Vuex가 하는 일은 '수정'이다. 수정 후 해체 작업량이 줄어들 것 같아 먼저 Vuex를 사용한다.

Vuex의 개념은 허공에서 이해하기에는 다소 추상적이지만 일단 사용하면 매우 편안합니다. 게다가 라우팅과 달리 Vuex 도입 이후에는 시나리오를 구분하지 않고 사용할 수 있습니다. 데이터 오염은 자연스럽게 해결되며 Vuex는 액션 => 돌연변이 => 저장 프로세스가 허용되면 상황이 정말 단순해질 것입니다. Vuex를 도입하는 프로세스는 기본적으로 데이터를 저장소로 전송하고 데이터 작업을 액션, 게터로 분산시키는 것입니다. , 변이, 동기화를 동시에 수행할 수 있으므로 데이터 작업이 필요하지 않으므로 코드 양이 줄어듭니다.

이후에는 라우팅을 소개하기 시작했는데, 처음에는 뷰를 어떻게 나누어야 할지 고민이었는데, 이론상으로는 메인 인터페이스를 세분화해야 하는지 의문이 듭니다. , 매우 세밀하게 나눌 수 있지만 응용 프로그램의 실제 사용 시나리오와 결합하면 인터페이스 전환이 상대적으로 빈번하고 구성 요소를 자주 로드 및 언로드하는 데 비용이 많이 듭니다. 더욱이 긴밀하게 결합된 구성 요소를 다른 보기로 분할하려면 비용이 많이 듭니다. 이득을 볼 가치가 없는 많은 상태 정보를 기록하다 보니 결국 포기하고 안 하게 되면서 메인 화면이 계속 나뉘게 됩니다. 세 가지 뷰의 액세스 중첩이 높지 않다는 점을 고려하면 컴포넌트를 비동기적으로 로드하고, 액세스할 때만 컴포넌트를 로드하는 것이 당연합니다. Vue 자체는 비동기 컴포넌트를 지원하므로 이 문제는 매우 간단해집니다. Promise를 반환할 수 있고 어떤 방식으로든 구성요소를 얻을 수 있습니다.

다음 단계는 Wild Dog Cloud에 연결하여 실제 사용자 관리 및 데이터 통계를 얻는 것입니다. Wild Dog Cloud는 이를 통해 js만을 사용하여 완전한 웹 애플리케이션을 개발할 수 있습니다. . 이런 방식으로 localStorage의 모든 이전 작업은 Wild Dog Cloud의 작업으로 변경되어야 하며, 데이터가 클라우드에 도달하면 더욱 안정적이 됩니다.

이제 2차 리팩토링이 완료되었습니다. 전체적인 비즈니스 코드가 많이 줄어든 느낌이지만, 결국 프레임워크 파일이 3개 추가되었네요. 파일이 원래 3개에서 2개로 줄었습니다. 모듈화를 위해 webpack 대신 seajs를 사용합니다. 왜냐하면 저는 여전히 webpack에 대해 관망하는 태도를 갖고 있기 때문입니다. 핵심은 webpack을 기반으로 개발된 코드가 많이 섞여 있다는 것입니다. 개인 제품은 코드를 네이티브가 아니게 만들고 이를 다중 페이지에서 실행할 수 없습니다. 시나리오에서 seajs는 로컬 캐싱과 결합할 때 webpack보다 더 많은 이점을 갖습니다. 물론 차이점은 jQuery와 Vue의 차이점과 마찬가지로 본질적으로 동일한 것이 아니며 사용 시나리오에 있습니다. 그것이 가장 적합합니다.

Postscript

두 번의 리팩토링 실습과 함정을 거쳐 Vue 프레임워크를 더 깊이 이해하게 되었습니다. Vue를 유연하고 자유롭게 사용하려면 개발자의 프로젝트 아키텍처 기능에 대한 최소 요구 사항이 있습니다. Vue를 최하위 계층에 도입하는 것은 인프라 빌더의 계획 능력에 대한 최소 요구사항이기도 합니다. 이는 jQuery 기술 스택에서는 찾을 수 없습니다. , 이것은 좋은 일이며 일반적인 추세입니다. 결국 진정한 자유는 규칙에만 존재합니다.

이 기사의 전체 코드는 Github에서 찾을 수 있습니다.