使用TypeScript编写vue项目也已经有了一段时间,笔者在刚刚使用TypeScript时候也是很茫然,不知道从何下手,感觉使用TypeScript写项目感觉很累赘并不像JavaScript那么灵活,因为TypeScript对于代码限制太多,在写代码的过程中时不时的就会抛出一个令你意想不到的错误,这一点笔者也是爬了不小的坑。可以使用了TypeScript一段时间之后,才知道TypeScript那是真的香(谁都逃不过的真香定理,O(∩_∩)O)。
笔者在之前使用Vue的时候,曾经提到过如何在项目中使用依赖注入的概念,使用依赖注入主要有两个目的:
同样在使用TypeScript编写项目的过程中同样也是使用了这种思路,但是也有些许的不一样的地方,笔者对于项目结构是这样划分的:
├─api // 请求数据接口
├─assets // 静态资源
├─components // 组件
│ ├─base // 基础组件
│ └─business // 业务组件
├─domain // 业务逻辑
├─interface // 接口
│ ├─other // 其他接口
│ ├─public // 公用接口
│ └─views // 页面接口
├─middleware // 中间件
├─mixins // 混入层
├─router // 路由层
├─store // 全局状态管理
├─style // 样式
│ ├─components // 组件
│ │ ├─base // 基础组件样式
│ │ └─business // 业务组件样式
│ ├─public // 公用样式
│ └─views // 页面样式
└─views // 页面
这样看上去,每一层都有其自己的职责不会项目影响只是相互依赖,对于项目的维护来说是很友好的,这里会出现一个问题,为什么要对项目结构进行划分呢?笔者所理解的是:
也已经说过各个分层之间有依赖关系,他们之间如何依赖又应该如何调配呢?对于前端来讲无论是什么项目,都是依赖于页面展开工作的,那么必定是以views层为中心,views又需要依赖于router,router需要注入到vue实例当中。
上图中assets没有提及到,对于assets用来存储一些静态文件,这一层尽量不要去与基础组件之间耦合在一起,这样做的话若其他项目用到该组件的时候,该组件就变了味道。
其实这里笔者想着重说的一点是,domain和views之间的引用,对于我来说业务层是用来拆分业务,使views和domain之间各做自己的事情,views更加的去关注页面该如何去展示数据,然而domain更加的关注业务逻辑部分。
domeDomain.ts
// 引入api
import domeAPI from "@/api/domainAPI.ts";
// 引入intaerface
import {tableItemInterface,queryDataInterface} from "@/interface/domeInterface.ts";
class DomeDomain {
public async getTableList (target: Object, propertyName: string, propertyDescriptor: PropertyDescriptor):PropertyDescriptor{
const data:queryDataInterface = propertyDescriptor.value();
propertyDescriptor.value = async function ():Promise<tableItemInterface[]>{
// 这里是业务逻辑
const {result:tableItemInterface[]} = await domeAPI.getTableList(data);
return result as Promise<tableItemInterface[]>;
}
return propertyDescriptor;
}
}
export default DomeDomain;
dome.vue
<template>
<div>
<el-table :data="list"/>
</div>
</template>
<script lang="ts">
import { Component, Vue} from 'vue-property-decorator';
// 引入intaerface
import {tableItemInterface,queryDataInterface} from "@/interface/domeInterface.ts";
// 引入业务类
import DomeDomain from "@/domain/DomeDomain.ts";
const domeDomain = new DomeDomain();
@Component()
export default class AddChargesButton extends Vue {
private tableList:tableItemInterface[] = [];
private queryData:queryDataInterface = {};
private pageInfo:{page:number,size:number}:{ page:1,
size:20};
@domeDomain.getTableList
private async getTableList(data:queryDataInterface):Promise<{pageInfo:any,query:queryDataInterface}>{
let {queryData:query,pageInfo} = this;
return {query,pageInfo};
}
private async queryTableList():Promise<void>{
try{
this.pageInfo.page = 2;
let {list} = await this.getTableList();
this.tableList = list;
}catch(error){
this.$message.error(error.message || error);
}
}
}
</script>
在上面的代码中,domeDomain中定义了一个getTableList的方法,因为这个地方需要使用修饰符的形式去修饰方法,用于去请求数据,然而在页面中的方法,可以无限次的复用,调用该方法的时候也可以对其参数进行调整之后再进行数据请求。
不用再去担心参数的的传递,只需要把所有的参数整合好,调用其对应的获取数据的方法就行了很方便。同样也达到了业务和页面表现的拆分。然而好处并不仅仅只有这些。相对应的在项目中同样解脱了store。让store做应该做的事情。
如果只是为了拆分业务的话不仅仅只限定于这一中方法,同样也可以直接再页面中使用domain业务类的实例,去调用实例的方法,或者是使用混入把业务部分使用混入的形式混入到对应的页面中。
原文:https://segmentfault.com/a/1190000021285842
随着JavaScript项目的成长,如果你不小心处理的话,他们往往会变得难以管理。我们发现自己常常陷入的一些问题: 当在创建新的页面时发现,很难重用或测试之前写的代码。当我们更深处地研究这些问题
Redis是一个开源(BSD许可),内存存储的数据结构服务器,可用作数据库,高速缓存和消息队列代理,它支持字符串、哈希表、列表、集合、有序集合,位图,hyperloglogs等数据类型
当一个集合中只包含整数,并且元素的个数不是很多的话,redis 会用整数集合作为底层存储,它的一个优点就是可以节省很多内存,虽然字典结构的效率很高,但是它的实现结构相对复杂并且会分配较多的内存空间
在 JavaScript 中数据结构通常总是被忽略,或者接触得不多。但是对于许多大厂而言,一般都需要你深刻了解如何管理数据。掌握数据结构也能够在解决问题时为你的工作提供帮助。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!