用TypeScript写前端

前言 优雅的API接口会让前端后端在对接过程中达成一些默契，提供一些愉悦的开发体验，对API接口的质量提升也有很大的一些帮助，本文罗列一些我们团队在日常开发过程中达成的一些共识，可能部分只适合我们自己

一、 什么是Refresh Token 说到 Refresh Token， 首先要提到的是 OAuth2.0 以及 Access Token: Access Token 和 Refresh Token

新项目来了，技术总监 开始排任务了，需要 张三 同学来实现采购单的功能，包含采购单的审核、拒绝等功能。于是 张三 编写了下面的代码：

一、需求描述 系统设计了 销售单、采购单、入库单、出库单、盘点单、移库单、生产计划单等等等等类型的单据，单据都有着 单据编号、单据明细、单据状态 等属性，而且每个单据都有不同的状态，但又都包含了 待审

一、写在前面 本文使用 Vue3 + Vite + TypeScript + Element-Plus 作为主要的环境和前提，不讨论其他状况下的问题。 在常见的后台管理系统中，前端往往需要大量的表格来

一、写在前面 第一天 写在前面，先看几段代码，用你的大脑编译运行一下试试？ No errors, no warnings! 乍一看，这代码会打印 1.0.0，于是跑一下试试？ 原来是 getter/s

一、何为魔法值 说到 魔法值，就不得不提一下 阿里巴巴开发规范 里一条代码规范的要求： 魔法值 的前身是 魔数，关于 魔数 的解释，你可以参考知乎上的这个问题 编程中的「魔数」（magic numbe

一、注释的必要性 此处省略八百字。 二、AirPower使用注释的示例 类的注释 示例 效果 属性的注释 示例 效果 方法的注释 示例 效果 装饰器的注释 示例 效果 装饰器参数的注释 示例 效果 H

开源项目地址： Gitee / Github 🎉 这是个什么项目 AirPower, 一个基于TypeScript的开发工具包, 内置了数据转换、装饰器、时间日期处理、加解密与散列、文件处理、常用枚举

1、前言 早前的一些文章中提到的我们在前端使用TypeScript装饰器和面向对象设计的方案作为日常的业务开发方式，引来了不少的争议和讨论，虽然我们也使用了Hooks来实现一些视图层公共代码的抽离，但

写在前面 早前写过几篇关于我们在前端中使用面向对象来做一些开发的文章，得到了很多兄弟的中肯评论和友好建议，也得到了很多不太一样的声音。 关于OOP和FP一些争议的说明，我们也专门出了一篇《用TypeS

写在前面 也许跟大部分的前端开发者不同，我们使用了 Vue3 和 TypeScript， 但我们也许是又回到了 老古董 的编程方式中， 也许是习惯了 面向对象(OOP) ，又或者是跑了一圈， 相比现在

前言 前几篇文章写了我们在前端使用了大量的面向对象的思维来做前端开发，有很多朋友也展开了激烈的讨论，很有意思。 函数式编程的优势今天不讲，我们今天只讲讲 TypeScript 中面向对象在前端开发中怎

把前端写成了后端模样 上文中有提到，我们没有像目前流行的一样，使用 Hooks、interface(或Type)，而是大量的选择了面向对象的思维：“甚至是照搬了用Java和SpringBoot在写后端

一、 先贴实现效果图 该表单有如下验证规则： 昵称只能输入中文，必填 年龄 18-50 必填 性别默认女 从字典选择 手机号格式验证 选填 简介选填，有输入限制 二、 实现方案 1. 声明 @Form

一、当前一些写前端的骚操作 先罗列一下见到过的一些写法吧：） 1. interface(或Type)一把梭 掘金上很多文章，一提到 TypeScript，那不得先用 interface 或者 type

一、先来看实现后的代码 1. view层 2. Model层 上述模型中一些项目中的其他依赖就不再一一附上了， 比如： 基类BaseEntity(其中包含了一些固定实体必须包含的字段，如 id cre

一、 先来看一张图 二、 解释下这张图 接口字段命名方式乱七八糟 驼峰下划线都有 有的名称不是我们想要的 比如 description 前端想用 remark 来替代 承诺是 数组 的数据返回了 nu

一、写在前面 前一篇文章《用AirPower4J，我们来写个后端服务吧》 是来水一篇，主要是顺带给前端项目写个后端的api服务， 略简单，入门级。后续再丰富吧：） 前端主要使用的是 Vue3 Type