规范化

问题：原生js 代码走到一个中央报错，后续代码无奈执行 vue与原生js不同：原生js 代码走到一个中央报错，后续代码无奈执行vue 多个生命周期，前一个生命周期的代码有了bug，后一个生命周期的代码还会执行 如何解决js代码出错，而后继续执行呢 try{}catch(err){}finally{} 解决好哪些状况，能够显得代码健壮性好呢？后端返回的数据类型多样，比方Object,Array,null,前端都思考到了用户不按惯例出牌，不按程序操作，前端是否束缚或者给出适合提醒（防暴力点击）适配各种分辨率，B端element-ui的el-table应用min-width。 C端流动列表页应用min-height:100vh用户体验，（1）B端：当页面内容居多时，能不能跳转到第一次出错的地位（2）B端：新增胜利，返回列表页时，能不能在缓存表单数据的状况下，再次调用查问接口 （3）C端：图片因为带宽过低或者网络不稳固未能加载到图片，应用@error办法，再次加载一次图片&t={$index} beforeRouteEnter(to, from, next) { next(async (vm) => { //因为当钩子执行前，组件实例还没被创立 if ( from.path == vm.questionnaireCreateUrl || from.path == vm.questionnaireViewUrl || from.path == vm.questionnaireModifyUrl ) { vm.resetForm(); await vm.getList(); } }); },加油哦，冲鸭！！！！！

前端-标准-elint代码格式化eslint配置文件// .eslintignore文件// 不检测iconfont.js文件**/iconfont.jsroot = true [*]charset = utf-8end_of_line = lfindent_size = 2indent_style = spaceinsert_final_newline = truetrim_trailing_whitespace = true常见命令主动格式化修复src文件夹下文件：eslint --fix src自动检测并列举不合乎的格局：eslint src检测指定文件夹下的.js和.vue文件：eslint --ext .js,.vue src依据配置文件检测指定类型文件：eslint --config .eslintrc.js --ext .js,.vue src设置代码跳过eslint检测不检测当行：// eslint-disable-line不检测下一行：// eslint-disable-next-line整个文件不检测：头部放/* eslint-disable */跳过多行： /* eslint-disable */function a() { return this;}/* eslint-enable */

文件局部文件夹： 小驼峰，尽量简洁，一眼能看出什么用途内容，示例：user, userSetting 文件名(js/css/vue/jsx/png)： 小驼峰，示例：userSetting.js/css/vue/jsx/png js局部模块，组件，类名： 大驼峰，示例：MyTestName js常量： 大写，多个单词两头用下划线，示例：MY_TEST_NAME js办法名： 小驼峰，尽量语义化，可动词前缀，示例：getTableData 路由地址： 小驼峰，长的话能够局部单词缩写，但须要语义明确，示例：sysSetting css局部css款式名： 小写，中横线链接，示例：flex-between 其余局部其余未说明均为小驼峰，简洁，语义化

通知EditorConfig插件，这是根文件，不必持续往上查找 root = true 匹配全副文件 [*] 设置字符集 charset = utf-8 缩进格调，可选space、tab indent_style = space 缩进的空格数 indent_size = 2 结尾换行符，可选lf、cr、crlf end_of_line = lf 在文件结尾插入新行 insert_final_newline = true 删除一行中的前后空格 trim_trailing_whitespace = true 匹配md结尾的文件 [*.md] insert_final_newline = false trim_trailing_whitespace = false

命名格调类名应用UpperCamelCase格调,但下列情景除外: DO: Data Object. 与数据库表构造一一对应,通过DAO层向上传输数据源对象BO: Business Object,业务对象. 由Service层输入的封装业务逻辑的对象DTO: Data Transfer Object,数据传输对象. Service或Manager向外传输的对象VO: View Object,显示对象. 通常是Web向模板渲染引擎层传输的对象AO: Application Object,利用对象. 在Web层与Service层之间形象复用的对象模型PO: POJO缩写,Plain Ordinary Java Object. 专指只有setter/getter/toString的简略类,包含DO,DTO,BO,VO等, 禁止应用xxxPOJO来命名UID办法名,参数名,成员变量,局部变量都对立应用lowerCamelcase格调常量命名全副大写,单词间用下划线隔开, 力求语义表白残缺分明,不要嫌名字长抽象类命名应用Abstract或者Base结尾异样类命名应用Exception结尾测试类命名要以要测试的类的名称命名,以Test结尾类型与中括号紧挨来示意数组POJO类中布尔类型的变量都不要加is前缀,在局部框架中会引起序列化谬误包名对立应用小写,点分隔符之间有且仅有一个天然语义的英语单词.包名对立应用复数模式.然而类名如果有复数含意,能够应用复数模式杜绝不标准的缩写,防止望文不知义为了达到代码自解释的指标,任何自定义的编程元素在命名时,应用尽量残缺的单词组合来表白含意在常量与变量命名的同时,示意类型的名词放在词尾,以晋升辨识度如果模块,接口,类,办法应用了设计模式,在命名时须要体现出设计模式接口类中的办法和属性不要加任何润饰符号(不要加public), 放弃代码的简洁尽量不要在接口中定义变量,如果肯定要定义变量,肯定是与接口办法无关的,并且是整个利用的根底变量 接口办法签名: void commit()接口根底常量: String COMPANY="Oxford"接口和实现类: 对于Service和DAO类,基于SOA的理念,裸露进去的服务肯定是接口,外部的实现类用Impl的后缀与接口的区别如果是形容能力的接口名称,去对应的形容词为接口(-able的模式)枚举类带上Enum后缀,枚举成员名称需全副大写 枚举类是非凡的类,域成员均为常量,且构造方法被默认强制是公有的各层命名标准: Service或者DAO层办法命名标准: 获取单个对象的办法用get做前缀获取多个对象的办法用list做前缀 ,复数模式结尾获取统计值的办法用count做前缀插入方法应用save或者insert做前缀删除的办法应用remove或者delete做前缀批改的办法应用update做前缀畛域模型命名标准: 数据对象: XxxDO,Xxx为数据表名数据传输对象: XxxDTO,Xxx为业务畛域相干的名称展现对象: XxxVO,xxx个别为网页名称POJO为DO,DTO,BO,VO的统称,禁止命名成XxxPOJO 常量定义不容许任何未经事后定义的常量呈现在代码中在long或者Long赋值时，数值后应用大写的L, 不能是小写的l. 因为小写容易和数字1混同,造成误会不要应用一个常量类保护所有常量,要按常量的性能进行归类,离开保护 大而全的常量类横七竖八,应用查找性能能力定位到批改的常量,不利于了解和保护常量的复用档次有五层: 跨利用共享常量: 搁置在二方库中,通常是client.jar中的constant目录下利用类共享常量 搁置在一方库中,通常是子模块中的constant目录下子工程内共享常量 在以后子工程的constant目录下包内共享常量 在以后包的constant目录下类内共享常量 间接在类外部private static final定义如果变量值仅在一个固定范畴内变动,应用enum类型定义 如果存在名称之外的延长属性应应用enum类型,比方节令,示意一年中第几个节令: public enum SeasonEnum {SPRING(1),SUMMER(2),AUTUMN(3),WINTER(4);private int seq;SeasonEnum(int seq) { this.seq=seq;}} 代码格局大括号的应用约定: 如果大括号内为空,则简洁地写成 { } 即可,不须要换行如果是非空代码块: 左大括号前不换行左大括号后换行右大括号前换行右大括号后如果还有else则不换行示意终止的右大括号后必须换行小括号的应用约定: 左小括号和字符之间不要呈现空格右小括号和字符之间也不要呈现空格左大括号之前须要空格if,for,while,switch,do等保留字与括号之间都必须加空格任何二目,三目运算符左右两边都须要加一个空格 运算符包含: ...

规范化规范规范化是咱们践行前端工程化中重要的一部分 为什么有标准规范哪些须要规范化规范施行规范化的办法为什么有标准规范 软件开发须要多协同，不同开发者具备不同的编码习惯和爱好，不同的爱好减少我的项目保护老本，每个我的项目或者团队须要明确对立的规范哪些须要规范化规范 代码，文档，甚至是提交日志，开发过程中人为编写的内容，代码标准化标准最为重要（对立关键词和操作符左右空格，对立代码的缩进形式，对立是否应用分号结尾，对立变量函数的命名标准）施行规范化的办法 编码前人为的规范约定通过工具实现 Lint（更谨严牢靠，同时能够配合自动化工具，主动查看）常见的规范化实现形式 ESLint 工具应用定制 ESLint 校验规定ESLint 对 Typescript 的反对ESLint 联合自动化工具或者 Webpack基于 ESLint 的衍生工具Stylelint 工具的应用 （对css进行校验操作）ESLint最为支流的JavaScript Lint 工具， 监测 JS 代码品质ESLint 很容易对立开发者的编码格调ESLint 能够帮忙开发者晋升编码能力初始化我的项目，装置 ESLint 模块为开发依赖 装置：yarn add eslint --dev 实现 eslint 应用配置，编写问题代码，应用 eslint 执行检测 应用 yarn eslint 文件.js 时，会报错说未找到eslint 配置文件 通过yarn eslint --init 进行命令行交互 只查看语法查看语法发现问题查看语法发现问题并且对代码格调校验 装置过后生成 .eslintrc.js 文件 执行 yarn eslint ./文件.js，查看谬误 配置文件# .eslintrc.jsmodule.exports = { env: { browser: true, es2021: true }, extends: [ 'standard' ], parserOptions: { ecmaVersion: 12 }, rules: { 'no-alert':"error" }}env 设置运行环境，参数并不互斥 ...