JavaScript의 React 프레임워크 원리에 대한 심층적인 이해_기본 지식

두 달 전에 React에 대해 어떻게 생각했는지 물으셨다면 아마도 이렇게 말했을 것입니다.

• 내 템플릿은 어디에 있나요? JSX의 HTML은 어떤 이상한 일을 하고 있나요?

제가 이해를 못했기 때문이에요

맹세합니다. React는 확실히 올바른 방향으로 가고 있습니다. 제 말을 들어주세요.

옛 MVC

대화형 애플리케이션의 모든 악의 근원은 관리 상태에 있습니다.
"전통적인" 방식은 MVC 아키텍처 또는 일부 변형입니다.

MVC는 모델을 정보의 단일 소스로 제시합니다. 즉, 모든 국가가 그곳에 살고 있습니다.
뷰는 모델에서 파생되며 동기화를 유지해야 합니다.
모드가 바뀌면 볼 수 없습니다.

마지막으로 사용자 상호 작용은 모델을 업데이트하는 컨트롤러에 의해 캡처됩니다.
지금까지는 너무 좋았습니다.

모델이 변경되면 뷰를 렌더링해야 합니다

아주 간단해 보입니다. 먼저 뷰, 즉 모델 상태를 DOM으로 전송하는 방법을 설명해야 합니다. 그런 다음 사용자가 작업을 수행하자마자 모델을 업데이트하고 전체 페이지를 다시 렌더링해야 합니다...그렇지 않습니까? 안타깝게도 다음 두 가지 이유 때문에 이는 그리 간단하지 않습니다.

• DOM에는 실제로 텍스트 입력 상자의 내용과 같은 일종의 상태가 있습니다. DOM을 완전히 무효화하고 다시 렌더링하면 해당 내용이 손실됩니다.
• DOM 작업(예: 노드 삭제 및 삽입)은 매우 느립니다. 빈번한 렌더링은 심각한 성능 문제를 일으킬 수 있습니다.

그러면 이러한 문제를 피하면서 모델과 뷰의 동기화를 유지하면 어떨까요?
데이터 바인딩

지난 3년 동안 이 문제를 해결하기 위해 도입된 멀티 프레임워크 기능 중 가장 일반적으로 사용되는 것은 데이터 바인딩입니다.

데이터 바인딩은 자동으로 모델과 뷰의 동기화를 유지합니다. 일반적으로 JavaScript에서는 개체와 DOM으로 표시됩니다.

애플리케이션의 다양한 청크 간에 종속성을 선언할 수 있도록 하여 이러한 동기화를 패키징합니다. 상태 변경 사항은 애플리케이션 전체에 전파되며 모든 종속 블록은 자동으로 업데이트됩니다.

몇몇 유명한 프레임워크에서 실제로 어떻게 작동하는지 살펴보겠습니다.

녹아웃

Knockout은 MVVM(Model-View-ViewModel) 방식을 옹호하고 "뷰" 부분을 구현하도록 도와줍니다.

// View (a template)
<p>First name: <input data-bind="value: firstName" /></p> 
<p>Last name: <input data-bind="value: lastName" /></p> 
<h2>Hello, <span data-bind="text: fullName"> </span>!</h2>
// ViewModel (diplay data... and logic&#63;)
var ViewModel = function(first, last) { 
 this.firstName = ko.observable(first);
 this.lastName = ko.observable(last);
 this.fullName = ko.pureComputed(function() {
   // Knockout tracks dependencies automatically. It knows that fullName depends on firstName and lastName, because these get called when evaluating fullName.
   return this.firstName() + " " + this.lastName();
 }, this);
};

여기서 입력 값을 변경해도 범위는 변경됩니다. 바인딩하기 위해 코드를 작성할 필요가 없습니다. 정말 멋지죠?

잠깐, 모델이 진실의 근원이 아닌가요? 여기의 뷰 모델은 상태를 전혀 얻지 못하나요? 흥미로운 질문입니다.

각도

Angular는 모델과 뷰의 동기화를 유지하는 방식으로 데이터 바인딩을 설명합니다.

그런데... 뷰가 모델과 직접 소통해야 할까요? 곧 긴밀하게 결합될까요?

어떤 일이 있어도 hello world 예제를 살펴보겠습니다.

// View (a template) 
<div ng-controller="HelloController as hello"> 
 <label>Name:</label>
 <input type="text" ng-model="hello.firstName">
 <input type="text" ng-model="hello.lastName">
 <h1>Hello {{hello.fullName()}}!</h1>
</div>
 
// Controller 
angular.module('helloApp', []) 
.controller('HelloController', function() {
 var hello = this;
 hello.fullName = function() {
  return hello.firstName + hello.lastName;
 };
});

从这个示例中，看起来像是控制器有了状态，并且有类似模型的行为 - 或者也许是一个视图模型? 假设模型在其它的地方, 那它是如何保持与控制器的同步的呢?

我的头开始有点儿疼了.
数据绑定的问题

数据绑定在小的例子中运行起来很不错。不过，随着你的应用规模变大，你可能会遇到下面这些问题.

声明的依赖会很快引入循环

最经常要处理的问题就是对付状态中变化的副作用。这张图来自 Flux 介绍，它解释了依赖是如何开始挖坑的：

你能预计到当一个模型发生变化时跟着会发生什么改变么? 当依赖发生变化时，对于可以任意次序执行的代码你很难推理出问题的起因。
模板和展示逻辑被人为的分离

视图扮演了什么角色呢? 它扮演的就是向用户展示数据的角色。视图模型扮演的角色又是什么呢? 它扮演的也是向用户展示数据的角色？有啥不同？完全没有！

• 毫无疑问，模板割裂了计数 ~ Pete Hunt

最后，视图组件应该能操作其数据并以需要的格式对数据进行展示。然后，所有的模板语言本质上都是有缺陷的：它们从来都不能达到跟代码一样的表现力和功能。

很简单， {{# each}}, ng-repeat 和 databind="foreach" 这些都是针对 JavaScript 中某些原生和琐碎事务的拙劣替代物。而它们不会更进一步走得更远。因此它们不会为你提供过滤器或者映射。

数据绑定是应重新渲染而生的小技巧

什么是圣杯不再我们的讨论之列。每个人总是想要得到的是，当状态发生变化时能重新对整个应用进行渲染。这样，我们就不用去处理所有麻烦问题的根源了：状态总是会随着时间发生变化——给定任何特定的状态，我们就可以简单的描述出应用回是什么样子的。

好了，问题清楚了。哥们，我希望某些大公司能组个超能天才开发者团来真正解决这个问题...
拥抱Facebook的React

事实证明他们做到了。React实现了一个虚拟的DOM，一种给我们带来的圣杯的利器.
虚拟的DOM是啥东西呢?

很高兴你能这么问？让我们来看看一个简单React示例.

var Hello = React.createClass({ 
  render: function() {
    return <div>Hello {this.props.name}</div>;
  }
});
React.render(<Hello name="World" />, document.getElementById('container'));

这就是一个React组件的所有API。你必须要有一个渲染方法。复杂吧，呵呵?

OK, 但是

是什么意思? 那不是 JavaScript 啊! 对了，它就不是.

你的新伙伴，JSX

这段代码实际上是用 JSX 写的，它是 JavaScript 的一个超集，包含了用于定义组件的语法。上面的代码会被编译成 JavaScript，因此实际上会变成：

var Hello = React.createClass({displayName: "Hello", 
  render: function() {
    return React.createElement("div", null, "Hello ", this.props.name);
  }
});
React.render(React.createElement(Hello, {name: "World"}), document.getElementById('container'));

你明白这段对 createElement 调用的代码么? 这些对象组成了虚拟 DOM 的实现。

很简单 : React 首先在内存中对应用的整个结构进行了组装。然后它会把这个结构装换成实际的 DOM 节点并将其插入浏览器的 DOM 中。

OK，但是用这些奇怪的 createElement 函数编写 HTML 的目的是什么呢？

虚拟的DOM就是快

我们已经讨论过, 操作 DOM 消耗大得离谱，因此它必须以尽可能少的时间完成。

React 的虚拟 DOM 使得两棵 DOM 结构的比对真正快起来，并且能确切的找到它们之间有什么变化. 如此，React 就能计算出更新 DOM 所需要做出的最小变更。

实话说，React 能比对两棵 DOM 树，找出它所要执行的最小操作集。这有两个意义:

1. 如果一个带有文本的输入框被重新渲染，React 会知道它有的内容, 它不会碰那个碰那个输入框。不会有状态发生丢失的!
2. 比对虚拟 DOM 开销一点也不昂贵，因此我们想怎么比对都可以。当其准备好要对 DOM 进行实际的修改时，它只会进行最少量的操作。没有额外的拖慢布局之虞!

那我们还要在状态发生变化时记住这两个对整个 app 进行重新渲染的问题么?

这都是过去式了。

React 将状态映射到 DOM

React 中只有虚拟 DOM 的渲染和比对是神奇的部分。其优秀性能是使得我们拥有简化了许多的整理架构的基础。有多简单呢?

React 组件都是幂等（一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同）的函数。它们能在任意一个实时的点来描述你的UI。~ Pete Hunt, React: 对最佳实践的重新思考

简单的幂等函数。

React 组件整个就是这么一个东西，真的。它将当前的应用状态映射到了 DOM。并且你也拥有JavaScript的全部能力去描述你的 UI——循环，函数，作用域，组合，模块 - 不是一个蹩脚的模板语言哦.

var CommentList = React.createClass({ 
 render: function() {
  var commentNodes = this.props.data.map(function (comment) {
   return (    <Comment author={comment.author}>
     {comment.text}    </Comment>
   );
  });
  return (   <div className="commentList">
    {commentNodes}   </div>
  );
 }
});
 
var CommentBox = React.createClass({ 
 render: function() {
  return (   <div className="commentBox">
    <h1>Comments</h1>
    <CommentList data={this.props.data} />
   </div>
  );
 }
});
 
React.render( 
 <CommentBox data={data} />,
 document.getElementById('content')
);

今天就开始使用 React

React 一开始会有点令人生畏。它提出了一个实在是太大了点的模式转变，这总有点令人不舒服。不过，当你开始使用它时其优势会变得清楚起来。

React 文档很优秀. 你应该照着教程对其进行一下尝试。我确信如果你给它一个机会，你肯定会爱上她。

编码快乐!

본 웹사이트의 성명

본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.