이번에는 Vue 패밀리 버킷 프로젝트에 대한 자세한 실제 설명을 가져오겠습니다. Vue 패밀리 버킷을 사용하여 프로젝트를 구현할 때 주의 사항은 무엇입니까?
프런트 엔드 관점에서 볼 때 Vue는 현재 가장 이상적인 프런트 엔드 MVVM 프레임워크라고 할 수 있습니다. 모든 것이 인터페이스를 제공하며 시작하기 쉽습니다. 이 기사에서는 Vue 제품군 버킷의 사용을 기록합니다. Vue+Vue-router+Vuex)를 통해 jQuery를 재구성합니다. +템플릿 프로젝트의 프로세스와 해당 기간 동안의 이익.
시작하기
Vue의 공식 문서는 Vue를 배우기 위한 최고의 튜토리얼입니다. 아마도 프레임워크 작성자가 디자인 배경 출신이고 백엔드 배경 지식이 없기 때문에 Vue에서는 다양한 추상 개념을 가장 이해하기 쉬운 방식으로 설명할 수 있습니다. Vue, Vue-router, Vuex의 개념을 간략하게 소개합니다. 종합적인 학습을 위해서는 공식 문서를 참고하는 것이 좋습니다.
Vue
Vue의 핵심 기능은 양방향 바인딩으로, 인터페이스 중심의 데이터 변경과 데이터 중심의 인터페이스 변경을 자동으로 실현할 수 있어 프런트 엔드가 풍부한 대화형 애플리케이션의 개발 비용을 크게 줄일 수 있습니다. 유사한 프레임워크인 Vue가 두 개 이상 있지만 Vue의 구현은 ES5의 기본 기능을 활용하여 성능 면에서 특정 이점을 제공합니다.
Vue 라우터
Vue-router는 URL과 구성 요소 간의 매핑 관계를 구성하고 구성 요소에 대한 URL 변경에 자동으로 응답하는 데 사용되는 공식 경로이므로 개발자는 구성 요소 개발에만 집중하면 되며 라우팅은 관련 문제를 해결하는 데 도움이 됩니다. 사소한 질문.
Vuex
Vuex는 복잡한 데이터 흐름 상황을 처리하기 위해 중앙 집중식 데이터 관리 모델을 제공합니다. 예를 들어 여러 구성 요소가 데이터를 공유하지만 독립적으로 작동하므로 동기화된 데이터가 동기화되지 않거나 Object 객체의 후크로 인해 발생할 수 있습니다. Node.js 메모리에서 동일한 인스턴스를 가리키면 원본 데이터가 조작되면 다른 구성 요소에 오염이 발생합니다. 이때 보다 체계적인 데이터 작업 모드가 필요합니다. 바로 Vuex입니다.
기술선택
jQuery와 비교
Vue의 기본 개념을 이해한 후에는 이러한 것들이 실제로 내 비즈니스에 필요한지 궁금해하면서 무의식적으로 jQuery 기술 스택과 확실히 비교할 것입니다.
우선 MVVM으로 해결했던 문제를 jQuery로 해결할 수 있을까? 대답은 '예'입니다. 양식을 제출할 때 jQuery를 사용하여 입력 값을 하나씩 가져오는 것을 기억하시나요? 이는 인터페이스 기반 데이터입니다. 비동기식 대화형 기능을 수행한 경우 jQuery를 사용하여 인터페이스의 다양한 요소에 Ajax 데이터를 채운 경험이 있어야 합니다. 가능하긴 하지만 좀 번거롭긴 하지만, 양식 검증 플러그인과 프런트엔드 템플릿 엔진을 사용하더라도 여전히 실행 중인 각 노드에서 검증 방법과 렌더링 방법을 수동으로 호출해야 하므로 괜찮습니다. 웹사이트 페이지를 만들려고 하는데, 요구사항이 어느 정도 복잡할 경우에는 큰 부담이 됩니다.
라우팅의 본질은 URL을 작동하여 인터페이스를 유지 관리하는 것입니다. 이는 라우팅 요구 사항이 생성되는 한 실제로는 관련이 없습니다. jQuery 기반 프로젝트는 단지 경로를 다시 만드는 것뿐입니다. jQuery 시대에는 단일 페이지 애플리케이션이 거의 만들어지지 않습니다.
Vuex는 완전히 양방향 바인딩 확장을 기반으로 합니다. 이는 데이터와 컴포넌트 사이에 브로커를 추가하는 것과 같습니다. 컴포넌트는 데이터를 직접 작동할 수 없으며 브로커가 구현합니다. 너무 많은 사람과 너무 많은 손으로 인해 발생하는 예측할 수 없는 다양한 문제를 해결하고 데이터를 애플리케이션 외부로 이동하기 위해 구성 요소 간의 데이터 오염 문제를 제거하기 위해 특별히 저장소를 구축했습니다. jQuery는 데이터를 완전히 수동으로 조작하고 예상치 못한 상황이 전혀 발생하지 않기 때문에 jQuery에는 이러한 요구가 없다고 해야 합니다.
적용 가능한 시나리오
jQuery와 비교해 보면 Vue의 적용 가능한 시나리오는 개발 관점에서 볼 때 더 복잡한 상호 작용이 있는 프로젝트가 더 적합하며, 웹 사이트에 개별 페이지가 필요한 경우에는 콘텐츠 웹 사이트가 가장 적합하지 않습니다. , 예를 들어 장바구니 페이지를 부분적으로 사용할 수도 있습니다.
물론 이 모든 것은 IE8과 호환되지 않는다는 전제에 기초해야 합니다. 일부 2C 사이트가 Vue를 사용하는 것을 보았기 때문에 이 프런트 엔드 사용자는 어떻게 상사를 속였습니까?
프로젝트 분석
프로젝트 배경
이번 리팩토링 프로젝트는 이전 회사를 위해 개발된 프런트엔드 구성 요소 관리 시스템입니다. 요구 사항을 잘 알고 있기 때문에 이 프로젝트를 리팩토링하기로 결정했습니다. 중간 정도의 복잡성을 지닌 일반적인 단일 페이지 애플리케이션이며 사용하기에 더 적합합니다. 실습으로.
이 프로젝트의 배경은 아웃소싱 웹 사이트 구축 회사에서는 디자인 과정에서 재사용 가능한 많은 구성 요소가 축적되어 디자이너가 구성 요소를 미세 조정하여 페이지를 구성하고 이를 프런트 엔드에 전달하는 경우가 많다는 것입니다. 이론적으로는 이러한 구성 요소를 프런트 엔드에서도 재사용할 수 있지만 실제로는 프런트 엔드 전체 페이지를 매번 다시 구현해야 하므로 많은 인력이 낭비됩니다.
기능 요구사항
이 프로젝트의 아이디어는 모든 구성요소를 개발하고 이를 통합 플랫폼에 입력하여 관리하는 것입니다. 디자이너는 플랫폼으로 이동하여 구성요소를 선택하고 실시간으로 구성요소를 미리 보고 조정할 수 있습니다. 코드가 프런트 엔드에 전달되는 한 이 코드 문자열을 사용하여 플랫폼에서 디자이너가 수정한 구성 요소를 재현할 수 있습니다. 또한 컴포넌트의 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"
},
...
}
}구성 요소의 실제 코드를 가져온 후 결과를 페이지에 삽입하고 시간에 맞춰 업데이트하면 됩니다. HTML 및 CSS는 텍스트 콘텐츠를 직접 대체할 수 있습니다. js는 모듈식으로 도입되므로 모듈 콘텐츠만 대체되고 모듈은 오버로드되지 않습니다. 모듈 이름을 바꾼 후에는 전체 모듈을 교체해야 하므로 js 모듈 이름은 무작위입니다.
여기에 문제가 있습니다. 일부 구성 요소는 페이지에서 여러 번 사용해야 하므로 이 구성 요소의 js 선택기가 충돌합니다. 이 문제는 js 모듈의 임의 이름을 사용하여 해결할 수 있습니다. id는 구성 요소 개발 중에 사용됩니다. 플랫폼은 자동으로 임의의 문자열을 할당합니다. 이 문자열은 구성 요소 인스턴스 내에서 동일하며 이러한 방식으로 ${id}를 호출하면 달라집니다. 구성 요소의 상위 노드의 ID 또는 클래스로 사용되면 선택기 충돌이 해결됩니다. 문제는 구성 요소의 CSS
네임스페이스로 사용할 수도 있으므로 가능한 CSS 이름 충돌이 보이지 않게 해결될 수 있다는 것입니다. 이상이 프로젝트의 핵심 기능입니다.
또한, 독립형 버전에 대한 데이터 통계를 구현하기 위한 저장 방식으로 localStorage가 사용되며, 현재 브라우저의 구성요소 사용 기록과 각 사용에 대한 구성을 수집할 수 있지만 이는 주로 로컬 저장소의 동작입니다. 또한 프로젝트 자체 개발에도 사용됩니다. 프런트 엔드 템플릿과 구성 요소 템플릿의 경우 첫 번째 로드 후 localStorage를 사용하여 캐시됩니다. 이러한 콘텐츠에 대한 캐싱 전략은 영구적으로 저장되어야 합니다. 프로젝트 템플릿은 수동으로 업데이트해야 하며, 상황에 따라 구성 요소 템플릿을 결정해야 하며, 저장된 콘텐츠가 너무 많으면 정리하는 동안 하나씩 삭제하는 것은 비현실적입니다. 실수로 다른 애플리케이션의 저장소를 손상시키는 방법은 localStorage 작업을 캡슐화하는 것이며, 특수 접두사를 삭제할 때 로컬에 저장된 키를 탐색하고 일치하는지 확인하기만 하면 됩니다. 해당 값 검색 방법은 접두어를 역순으로 키에 추가한 다음 값을 검색해야 합니다.
또한 localStorage는 객체 유형에 대한 액세스를 용이하게 하기 위해 자동 변환도 지원합니다. 그러나 이 변환은 값이 일치할 때 문자를 맹목적으로 변환할 수 없습니다. 때로는 사용자가 실제로 객체 문자열을 저장했다가 꺼낼 때 그대로 가져오고 싶을 수도 있기 때문에 객체가 자동으로 전송됩니다. 값이 객체임을 감지하면 문자열로 변환된 다음 식별 문자열이 앞에 옵니다. 값 메소드는 이 식별을 감지한 후에만 다음 문자열을 객체에 복원합니다. 별로 안전하지 않습니다. 이 접두사는 고정되어 있으므로 이론상으로는 항상 복권 당첨자를 만날 수 있습니다. 이 문제에 대한 다른 더 나은 해결책이 있는지는 모르겠습니다.
이것이 프로젝트의 주요 기능 포인트입니다.
리팩터링
1개 재건축
첫 번째 리팩토링은 Vue만 사용했는데, 리팩토링 과정에서 가장 먼저 깨달은 것은 다양한 편의성이었습니다. 원래 템플릿 엔진을 호출하고 싶었던 것은 원래는 프레임워크에서 이벤트를 바인딩하려고 했으나 지금은 그렇습니다. 바인딩 및 기타 다양한 구문 설탕에서 직접 수행할 수 있습니다.
물론 가장 중요한 것은 양방향 바인딩을 기반으로 인터페이스와 데이터가 자동으로 연결될 수 있으므로 사람들이 프로그램에 어느 정도 자율성이 있다고 느끼게 됩니다. 정상적으로 작동하려면 개발자는 모든 단계를 미리 계획해야 합니다. 이는 jQuery보다 덜 자유롭습니다. 움직이는 벽돌을 예로 들면, jQuery는 벽돌을 쉽게 들어 올리고 멋진 방식으로 이동할 수 있는 특히 유연한 크레인과 같습니다. Vue는 벽돌을 특정 장소에서 다른 곳으로 옮기고 싶다고 말합니다. 특정 장소에서 일어나는 일은 어떻게 처리하느냐에 따라 달라지며, 버튼을 누르면 벽돌이 자동으로 이동할 수 있습니다.
두 방법 모두 장점과 단점이 있습니다. 크레인을 잘 운전하면 매우 유연할 수 있으며 도로의 구덩이를 피하기가 쉽습니다. 단점은 버튼을 계속해서 운전해야 한다는 것입니다. 한 번에 자동으로 주행하도록 프로그래밍되어 있지만 도로에서의 위치를 미리 설정해야 한다는 단점이 있습니다. 현장 점검을 실시하고 다른 모든 차량의 일정을 잡고 모든 상황을 명확하게 설명해야 합니다. 그렇지 않으면 차량이 전복되거나 충돌할 수 있습니다. jQuery에서 Vue로 전환하면 확실히 "행동하기 전에 계획을 세우도록" 강요하는 구속감을 느낄 것입니다. 차에 타기 전에는 그것에 대해 말할 수 없습니다.
재구성 기간 동안 작업의 큰 부분은 Vue 인스턴스를 구축하고, js 구석구석에 흩어져 있는 데이터를 데이터로 수집하고, 데이터를 비트 단위로 연산하는 과정을 메소드로 집중하고, 데이터 필터링 프로세스를 계산으로 집중하는 것입니다. 모든 구현 세부 사항을 명확하게 검토하고 각 구현 방법이 합리적인지 여부를 반성할 수 있습니다. 실제로 모든 요약이 완료되면 Vue는 원격 제어 버튼으로 크레인을 구동하는 원래 프로세스를 요약하는 것입니다. example 자동으로 실행될 수 있는 최종 프로젝트가 됩니다.
재구성 후 Vue의 다양한 기능에 의존하여 논리적 부분의 코드 양이 줄었습니다. 이 외에 프로젝트 자체에는 라우팅이 없기 때문에 새로 고침 페이지의 상태가 사라지는 문제가 있습니다. Vuex를 사용하지 않기 때문에 데이터 오염 구덩이가 발생하면 이를 해결하기 위해 딥 카피(deep copy)만 사용할 수 있으며, 컴포넌트 기반 개발 모델은 코드 구성을 더욱 단편화합니다.
2차 재건축
두 번째 재구성의 목표는 라우팅, Vuex, 코드 구성 및 Dingo Cloud 백엔드를 개선하는 것입니다.
첫 번째 리팩토링을 경험했지만 두 번째 리팩토링을 시작할 때 라우팅과 Vuex 중 어느 것을 먼저 구현해야 할지 아직도 조금 혼란스럽습니다. 생각해보면 라우팅이 하는 일은 '해체'이고, Vuex가 하는 일은 '수정'이다. 수정 후 해체 작업량이 줄어들 것 같아 먼저 Vuex를 사용한다.
Vuex의 개념은 허공에서 이해하기에는 다소 추상적이지만 일단 사용하면 매우 편안합니다. 또한 라우팅과 달리 Vuex 도입 이후에는 데이터 오염 문제를 구별하지 않고 사용할 수 있습니다. 자연스럽게 해결되고 Vuex는 액션 => 돌연변이 => 저장 프로세스가 승인되면 상황이 정말 간단해집니다. Vuex를 도입하는 프로세스는 기본적으로 데이터를 저장소로 전송하고 데이터 작업을 작업, 게터 및 돌연변이로 분산하는 것입니다. 필요하므로 코드를 작성하는 양이 조금 줄었습니다.
그 이후에는 라우팅을 소개하기 시작했는데, 처음에는 뷰를 어떻게 나눌지 고민이었는데, 이론상으로는 메인 인터페이스를 세분화해야 하는지 의문이 듭니다. 매우 세밀하게 나눌 수 있지만 실제 애플리케이션 사용 시나리오에 따르면 인터페이스 전환이 상대적으로 빈번하고 구성 요소를 자주 로드 및 언로드하는 데 많은 비용이 듭니다. 더욱이 긴밀하게 결합된 구성 요소를 여러 보기로 분할하려면 많은 상태 정보를 기록해야 합니다. , 이는 이득을 얻을 가치가 없습니다. 결국 우리는 포기하고 메인 뷰를 변경하지 않았습니다. 세 가지 뷰의 액세스 중첩이 높지 않다는 점을 고려하면 컴포넌트를 비동기식으로 로드하고, 액세스할 때만 컴포넌트를 로드하는 것이 자연스럽습니다. Vue 자체는 비동기식 컴포넌트를 지원하므로 가능한 한 매우 간단해집니다. Promise를 반환하면 어떤 방식으로든 구성요소를 얻을 수 있습니다.
다음으로 실제 사용자 관리 및 데이터 통계를 얻으려면 Wild Dog Cloud에 액세스해야 합니다. Wild Dog Cloud는 이를 통해 js만 사용하여 완전한 WEB 애플리케이션을 개발할 수 있습니다. . 이런 방식으로 localStorage의 모든 이전 작업은 Wild Dog Cloud의 작업으로 변경되어야 하며, 데이터가 클라우드에 도달하면 더욱 안정적이 됩니다.
이쯤 되면 2차 리팩토링이 완료된 셈이다. 전체적인 비즈니스 코드가 많이 줄어든 느낌이지만, 결국 프레임워크 파일이 3개나 추가된 셈이다. 원래 3~2개의 js 파일에서 12개 정도의 js 파일이 빠졌고, 개인적으로 마음에 들지 않아서 모듈화를 위해 webpack 대신 seajs를 사용하고 있습니다. Webpack은 여전히 관망하는 태도를 갖고 있으며, 아직은 사용할 필요성을 느끼지 않습니다. 핵심은 webpack을 기반으로 개발된 코드가 많은 비공개 항목과 혼합되어 코드가 네이티브가 아닌 것으로 만든다는 것입니다. 나는 그렇게 생각하지 않습니다. 다중 페이지 시나리오에서 seajs는 로컬 캐싱과 결합될 때 webpack보다 더 많은 이점을 갖습니다. 물론 그 차이점은 jQuery와 동일합니다. Vue. 핵심은 귀하에게 가장 적합한 시나리오에 있습니다.
후기
두 번의 리팩토링 실습과 함정을 거쳐 Vue 프레임워크를 더 깊이 이해하게 되었습니다. Vue를 유연하고 자유롭게 사용하려면 개발자의 프로젝트 아키텍처 기능에 대한 최소 요구 사항이 있습니다. 기본 사항 jQuery 기술 스택에는 존재하지 않는 시설 구축자의 계획 기능에 대한 최소 요구 사항도 있습니다. Vue를 사용하는 과정은 개발자가 자신의 규칙 시스템을 설정하도록 안내할 수도 있습니다. .. 이는 좋은 일이며 일반적인 추세입니다. 결국 진정한 자유는 규칙 내에서만 존재합니다.
이 기사의 사례를 읽은 후 방법을 마스터했다고 생각합니다. 더 흥미로운 정보를 보려면 PHP 중국어 웹사이트의 다른 관련 기사를 주목하세요!
추천 도서:
위 내용은 Vue 패밀리 버킷 프로젝트 실습에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
