최신 프론트엔드 프레임워크에 대한 우리의 이해에 대해 이야기해 봅시다.

이 장에서는 최신 프런트엔드 프레임워크에 대한 이해에 대해 설명합니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.

그렇다면 사람들은 왜 지금 다양한 프레임워크를 선택해야 할까요?

사실 지금 프레임워크를 선택해야 하는 이유는 본질적으로 우리가 직면한 요구 사항이 바뀌었기 때문입니다. 대화형 기능 없이 정보만 표시하는 페이지만 작성한다면 실제로 지금도 프레임워크를 선택할 필요가 없으며 작업을 완료하기 위해 CSS와 HTML 몇 줄만 작성하면 된다는 점을 누구나 이해해야 합니다. . 따라서 우리가 직면한 요구 사항이 더욱 복잡해졌기 때문에 애플리케이션은 런타임에 일부 상호 작용을 수행해야 하는 경우가 많습니다.

굵게 표시된 세 가지 중요한 단어는 Runtime입니다. 현대의 프런트엔드 개발에서는 우리가 개발하는 애플리케이션이 런타임 시 일부 상호 작용을 요구하는 경우가 많습니다. 초기에는 이러한 상호 작용이 슬라이드나 탭 전환 드롭다운 메뉴와 같은 단순한 상호 작용에 불과했습니다. jQuery를 사용하여 이러한 상호 작용을 구현하는 데는 문제가 없습니다. . 그러나 최신 프런트 엔드에 대한 우리의 목표는 웹을 사용하여 네이티브 애플리케이션을 PK하고 네이티브를 사용하여 PK하는 것입니다.

이제 우리는 jQuery를 사용하여 애플리케이션을 개발하면 코드를 유지 관리하기가 어렵다는 것을 알게 될 것입니다. 그러면 Vue, React 등과 같은 최신 프레임워크를 사용하면 유지 관리가 더 쉬워지는 이유는 무엇입니까?

Vue와 jQuery의 유일한 차이점은 선언적 vs. 명령적입니다.

생각해보면 jQuery를 사용하여 DOM을 운영하는 목적은 무엇일까요? 로컬에서 뷰를 업데이트하는 것, 즉 로컬에서 다시 렌더링하는 것입니다.

jQuery는 DOM을 작동하는 필수 방식과 필수 부분 업데이트 뷰인 반면, Vue, React, Angular 등과 같은 최신 주류 프레임워크는 모두 선언적 및 선언적 부분 업데이트 뷰입니다.

선언적 DOM 조작을 통해 애플리케이션을 더 쉽게 유지 관리할 수 있는 이유는 무엇입니까?

이 문제를 이해하기 위해 먼저 명령형과 선언형이 무엇인지 간략하게 소개하겠습니다.

Imperative

Imperative는 jQuery처럼 우리 모두가 뭔가를 하고 싶어하면 그냥 그 일을 하게 됩니다. . 단순하고 직접적이며 조잡합니다.

토글 효과와 같은 매우 간단한 장면을 상상해 보세요. 버튼을 클릭하여 색상을 전환하세요.

명령형으로 작성해야 합니다. 현재 색상이 그렇다면 다른 색상으로 변경해 보세요.

잘 생각해보면 실제로 두 가지 동작으로 나눌 수 있는데, 하나는 상태를 판단하는 것이고, 다른 하나는 DOM을 운영하는 것입니다.

그럼 선언적이란 무엇인가요? ?

선언적 선언적이란 상태와 뷰 사이의 매핑 관계를 기술한 후, 이러한 매핑 관계를 통해 DOM을 조작하거나, 구체적으로는 이러한 매핑 관계를 사용하여 DOM 노드를 생성하는 것입니다. 페이지. 예를 들어 Vue의 템플릿입니다. 템플릿의 기능은 상태와 DOM 간의 매핑 관계를 설명하는 것입니다.

Vue에서 템플릿을 사용하여 동일한 시나리오를 구현합니다. 템플릿을 사용하여 매핑 관계를 설명한 후 버튼을 클릭하면 색상 변수만 수정하면 요구 사항이 완료됩니다.

차이점이 보이나요?

신중하게 생각하고 Vue를 사용하여 동일한 요구 사항을 달성하면 논리적으로 동작과 상태가 하나만 있습니다. 그리고 jQuery는 상태 + DOM 작업이라는 두 가지 동작입니다.

그렇다면 선언적 접근 방식이 애플리케이션 코드 유지 관리의 복잡성을 단순화할 수 있는 이유는 무엇일까요?

상태 유지에만 집중할 수 있게 해주기 때문이죠. 이렇게 애플리케이션이 복잡해지면 사실 우리의 생각과 코드 관리 방식은 상태에만 국한되고 더 이상 모든 DOM 작업에 신경 쓸 필요가 없게 됩니다. 유지 관리가 크게 줄어 듭니다.

우리는 더 이상 DOM 작동 방법에 주의할 필요가 없습니다. 프레임워크가 자동으로 DOM 작동을 수행하기 때문에 상태에만 주의하면 됩니다.

그러나 애플리케이션이 특히 복잡하다면 상태 유지에만 집중해도 여전히 어렵다는 것을 알게 될 것입니다. 따라서 Vuex 및 Redux와 같은 기술 솔루션은 여전히 ​​어렵습니다. 등장했습니다.

렌더링이란 무엇인가요? 이전 소개 이후 현대 주류 프레임워크가 해결해야 할 가장 중요한 문제는 여전히 렌더링이라는 것을 알 수 있지만, 프레임워크마다 솔루션에 차이가 있습니다. 그렇다면 렌더링이란 무엇일까요?

이제 프런트 엔드를 개발할 때 애플리케이션은 실행 중에 다양한 상호 작용을 지속적으로 수행해야 합니다. 최신 주류 프레임워크를 사용하면 상태 유지 관리에 집중할 수 있습니다. 즉, 애플리케이션이 실행 중일 때 애플리케이션의 내부 상태가 계속 유지됩니다. 변화.

상태 생성 DOM을 페이지에 삽입하고 이를 사용자 인터페이스에 표시하는 과정을 렌더링이라고 합니다.

최신 프런트 엔드 프레임워크에 의한 렌더링 처리애플리케이션이 실행되면 내부 상태가 계속 변경됩니다. 이때 사용자 페이지의 특정 로컬 영역을 지속적으로 다시 설정해야 합니다. 렌더링되었습니다.

다시 렌더링하는 방법은 무엇입니까?

프레임워크를 사용하지 않는 프로젝트에서 간단한 함수를 작성할 때 가장 일반적으로 사용되는 가장 간단하고 조잡한 솔루션은 상태를 사용하여 새 DOM을 생성한 다음 innerHTML을 사용하여 교체하는 것입니다. 오래된 DOM.

제가 작성한 작은 함수 블록에는 이 방법을 사용하는 것이 문제가 되지 않습니다. 왜냐하면 함수에는 DOM 태그가 거의 포함되지 않기 때문입니다. 상태가 변경되면 내 함수 블록의 거의 모든 태그를 변경해야 하기 때문입니다. innerHTML을 사용해도 성능의 낭비는 별로 없고, 허용 가능한 범위 내이다.

그런데 프레임이 innerHTML로 교체되면 부분적으로 다시 렌더링되지 않고 전체 페이지가 새로 고쳐집니다. 프레임을 부분적으로 다시 렌더링할 수 있나요?

이 문제를 해결하려면 VirtualDOM일 수도 있지만 반드시 VirtualDOM일 필요는 없습니다. 또는 Angular의 더티 감지 프로세스일 수도 있습니다. Vue1.0과 마찬가지로 세분화된 바인딩을 사용하여 구현됩니다.

세결 제본이란 무엇인가요?

Fine-grained 바인딩은 특정 상태가 바인딩되면 페이지의 특정 레이블에 바인딩된다는 의미입니다. 즉, 특정 변수를 사용하는 템플릿에 10개의 태그가 있는 경우 변수는 10개의 특정 태그에 바인딩됩니다.

React 및 Angular와 비교하면 세분성이 상대적으로 낮습니다. 변경 감지는 실제로 어떤 상태 변수가 구체적인지 알 수 없으므로 격렬한 비교가 필요합니다. 보기를 부분적으로 업데이트해야 합니다.

Vue의 세분화된 바인딩은 실제로 상태가 변경되는 순간 어떤 상태가 변경되었는지 알고, 어떤 특정 태그가 이 상태를 사용하는지도 알 수 있으므로 훨씬 간단해집니다. 이 상태에 바인딩된 특정 태그를 직접 업데이트하여 로컬 업데이트의 목적을 달성합니다.

그러나 세분성이 너무 미세하고 종속성 추적에 대한 특정 오버헤드가 있기 때문에 실제로는 특정 비용이 발생합니다. 따라서 Vue2.0은 바인딩을 중간 세분성으로 조정하는 절충 솔루션을 채택하기 시작했습니다.

상태는 특정 레이블이 아닌 특정 구성 요소에 해당합니다. 이는 결국 DOM의 특정 레이블보다 구성 요소의 수가 적다는 장점이 있습니다. 많이. 그러나 이를 위해서는 한 가지 작업이 더 필요합니다. 상태가 변경되면 구성 요소에만 알림이 전달됩니다. 그러면 구성 요소는 업데이트할 DOM 태그를 어떻게 알 수 있습니까? ?

답은 VirtualDOM입니다.

즉, granularity를 ​​Medium으로 조정하면 컴포넌트 내부에서 VirtualDOM을 사용하여 다시 렌더링하기 위한 작업이 한 번 더 필요합니다.

Vue는 변경 감지 + VirtualDOM이라는 두 가지 기술 솔루션을 통해 프레임워크의 성능을 영리하게 향상시킵니다.

그래서 Vue2.0은 VirtualDOM이 너무 좋아서 VirtualDOM을 도입한 것이 아니라, 변경 감지와 결합된 VirtualDOM이 종속성 추적의 오버헤드 문제를 해결하기 위해 중간 세분성으로 바인딩을 조정할 수 있기 때문에 VirtualDOM을 도입했습니다.

변경 감지와 관련하여 Vue가 변경 감지를 구현하는 방법을 소개하는 특별 기사를 작성했습니다. 문.

그래서 변경 감지 방법에 따라 프레임워크가 렌더링되는 방식이 어느 정도 결정되었습니다.

VirtualDOM의 구현 원리에 대해 PPT를 작성했습니다. 관심이 있으시면 포털을 살펴보실 수 있습니다.

다른 하나는 템플릿 컴파일입니다. 사실 앞서 템플릿 컴파일에 대해 많이 언급하지 않았습니다. 템플릿의 기능은 상태와 DOM 간의 매핑 관계를 설명하는 것입니다. 템플릿을 통해 컴파일할 수 있으므로 이 렌더링 기능을 실행하면 VirtualDOM에서 제공하는 VNode를 얻을 수 있습니다. 실제로 앞서 VirtualDOM의 원리를 소개한 PPT를 본 적이 있다면 VirtualDOM이 노드를 비교하는 것이 실제로는 VNode를 비교하는 것임을 알 수 있습니다. . 템플릿 컴파일, 포털의 구현 원리를 소개하기 위해 특집 기사를 작성했습니다.

Summary

개인적으로는 요즘 프론트엔드에 좀 성급한 느낌이 들어서 많은 분들이 새로운 것에 주목하고 있습니다. 매일 새로운 기능이 출시되고, 내일 새로운 프레임워크가 출시될 것이라는 점에 동의하지만, 새로운 것을 추구하면서 그 본질을 볼 수 있기를 바랍니다. 모든 기술적 솔루션의 궁극적인 목표는 문제를 해결하는 것입니다. 솔루션은 완벽하지 않을 수도 있고, 솔루션이 많을 수도 있습니다. 그렇다면 이들 사이에는 어떤 장점과 단점이 있을까요? 문제를 해결하면서 각자는 어떤 절충안과 절충점을 만들었나요? 표면에 현혹되지 않으려면 현상을 통해 본질을 보아야 합니다.

위 내용은 최신 프론트엔드 프레임워크에 대한 우리의 이해에 대해 이야기해 봅시다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!