鸿蒙系统中JavaScript框架案例分析

鸿蒙系统中JavaScript框架案例分析
本文主要介绍"鸿蒙系统中JavaScript框架案例分析"，希望能处理您碰到的相关问题，让我们一起来看看这篇文章"鸿蒙系统中JavaScript框架案例分析"文章。
我在前文中介绍过鸿蒙Javascript框架，这几天终于把了JS库房编译通过，期间踩了许多坑，也为鸿蒙贡献了几个PR。今天，我们将逐行分析鸿蒙系统里的鸿蒙系统JS框架。
本文全部代码均基于鸿蒙当前最新版(版本为6777)ed递交日期为2020-09-10)。

使用鸿蒙系统JavaScript开发GUI这是一种类似小程序的轻应用模式。而这一点。MVVM模式中，V其实是由C++来承担的。JavaScript代码就是其中之一ViewModel层。
鸿蒙JS框架是零依赖的，只用于开发和包装过程中npm包装。包装后的代码不依赖任何npm包。让我们先来看看使用鸿蒙。JS框架是写出来的JS代码究竟长什么样。
exportdefault{
data(){return{count:1};
},
increase(){
++this.count;
},
decrease(){
–this.count;
},
}
如果我不告诉你这是鸿蒙，你甚至会觉得这是鸿蒙vue或是小程序。如果你把它独立放在一起。如果你把它独立放在一起。JS代码如下：
constvm=newViewModel({
data(){return{count:1};
},
increase(){
++this.count;
},
decrease(){
–this.count;
},
});console.log(vm.count);//1vm.increase();console.log(vm.count);//2vm.decrease();console.log(vm.count);///1复制代码
仓库里的一切JS代码实现了响应系统，充当响应系统MVVM里的ViewModel。
让我们逐一分析一下。

src目录中共有4个目录，共8个文档。其中一个是单元测试。还有一个性能分析。去除2个。index.js有四个有用的文档。这也是本文分析的重点。
src
├日日__test__
│└日日index.test.js
├日日core
│└日日index.js
├日日index.js
├日日observer
│├日日index.js
│├日日observer.js
│├日日subject.js
│└日日utils.js
└日日profiler
└日日index.js
首先是入口文档，src/index.js，只有二行代码：
import{ViewModel}from'./core';exportdefaultViewModel;复制代码
实际上是再次导出。
另一个相似的文档是src/observer/index.js，也是二行代码：
export{Observer}from'./observer';export{Subject}from'./subject复制代码
observer和subject实现了观察者模式。subject是主题，即被观测者。observer是观测者subject任何变化都要主动通知被观测者。这便是响应式。
这俩文档都用到了src/observer/utils.js，因此我们先分析一下utils文件。分为三部分。

第一部分
exportconstObserverStack={stack:[],
push(observer){this.stack.push(observer);
},
pop(){returnthis.stack.pop();
},
top(){returnthis.stack[this.stack.length-1];
}
};
首先是定义一个存放观测者的栈，遵循后进先出的原则，内部使用stack数组储存。
入栈操作push，和数组的push相同的函数，在栈顶放一个观测者observer。
出栈操作pop，和数组的pop相同的函数，在栈顶上删掉观测者，并回到被删除的观测者。
取栈顶元素top，和pop操作不同，top取出栈顶元素，但不删掉。

第二部分
exportconstSYMBOL_OBSERVABLE='__ob__';exportconstcanObserve=target=>typeoftarget==='object复制代码
字符串常量定义SYMBOL_OBSERVABLE。方便以后使用。
定义函数canObserve，目标是否能被观察到。只目标才能被观察到，因此使用它们。typeof判断目标类型。等等，好像有什么不对劲。target为null函数也会回到true。如果null不可观察，那么这便是一个bug。(我写这篇文章的时候已经提及了一个PR，并询问这种做法是不是预期的)。