精华内容
下载资源
问答
  • 前端代码埋点
    2020-12-28 16:48:44

    前端监控和前端埋点方案设计
    在线上项目中,需要统计产品中用户行为和使用情况,从而可以从用户和产品的角度去了解用户群体,从而升级和迭代产品,使其更加贴近用户。用户行为数据可以通过前端数据监控的方式获得,除此之外,前端还需要实现性能监控和异常监控。性能监控包括首屏加载时间、白屏时间、http请求时间和http响应时间。异常监控包括前端脚本执行报错等。

    实现前端监控有三个步骤:前端埋点和上报、数据处理和数据分析。本文针对整个前端监控,设计适用的方案。本文的主要内容分为:

    为什么需要前端监控
    常用前端埋点方案总结
    前端埋点方案选型和前端上报方案设计
    前端监控结果可视化展示系统的设计

    一、为什么需要前端监控
    前端监控的目的是:

    获取用户行为以及跟踪产品在用户端的使用情况,并以监控数据为基础,指明产品优化的方向。

    前端监控可以分为三类:数据监控、性能监控和异常监控。下面我们来一一的了解。

    (1)数据监控
    数据监控,顾名思义就是监听用户的行为。常见的数据监控包括:

    PV/UV:PV(page view),即页面浏览量或点击量。UV:指访问某个站点或点击某条新闻的不同IP地址的人数
    用户在每一个页面的停留时间
    用户通过什么入口来访问该网页
    用户在相应的页面中触发的行为
    统计这些数据是有意义的,比如我们知道了用户来源的渠道,可以促进产品的推广,知道用户在每一个页面停留的时间,可以针对停留较长的页面,增加广告推送等等。

    (2)性能监控
    性能监控指的是监听前端的性能,主要包括监听网页或者说产品在用户端的体验。常见的性能监控数据包括:

    不同用户,不同机型和不同系统下的首屏加载时间
    白屏时间
    http等请求的响应时间
    静态资源整体下载时间
    页面渲染时间
    页面交互动画完成时间
    这些性能监控的结果,可以展示前端性能的好坏,根据性能监测的结果可以进一步的去优化前端性能,比如兼容低版本浏览器的动画效果,加快首屏加载等等。

    (3)异常监控
    此外,产品的前端代码在执行过程中也会发生异常,因此需要引入异常监控。及时的上报异常情况,可以避免线上故障的发上。虽然大部分异常可以通过try catch的方式捕获,但是比如内存泄漏以及其他偶现的异常难以捕获。常见的需要监控的异常包括:

    Javascript的异常监控
    样式丢失的异常监控
    二、常用前端埋点方案总结
    在上一节中介绍了前端监控的作用,那么如何实现前端监控呢,实现前端监控的步骤为:前端埋点和上报、数据处理和数据分析。首要的步骤就是前端埋点和上报,也就是数据的收集阶段。数据收集的丰富性和准确性会影响对产品线上效果的判别结果。

    目前常见的前端埋点方法分为三种:代码埋点、可视化埋点和无痕埋点。下面一一介绍每一种埋点的方法。

    (1) 代码埋点
    代码埋点,就是以嵌入代码的形式进行埋点,比如需要监控用户的点击事件,会选择在用户点击时,插入一段代码,保存这个监听行为或者直接将监听行为以某一种数据格式直接传递给server端。此外比如需要统计产品的PV和UV的时候,需要在网页的初始化时,发送用户的访问信息等。

    代码埋点的优点:

    可以在任意时刻,精确的发送或保存所需要的数据信息。
    缺点:

    工作量较大,每一个组件的埋点都需要添加相应的代码
    (2)可视化埋点
    通过可视化交互的手段,代替代码埋点。将业务代码和埋点代码分离,提供一个可视化交互的页面,输入为业务代码,通过这个可视化系统,可以在业务代码中自定义的增加埋点事件等等,最后输出的代码耦合了业务代码和埋点代码。

    可视化埋点听起来比较高大上,实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。

    缺点:

    可视化埋点可以埋点的控件有限,不能手动定制。
    (3)无埋点
    无埋点并不是说不需要埋点,而是全部埋点,前端的任意一个事件都被绑定一个标识,所有的事件都别记录下来。通过定期上传记录文件,配合文件解析,解析出来我们想要的数据,并生成可视化报告供专业人员分析因此实现“无埋点”统计。

    从语言层面实现无埋点也很简单,比如从页面的js代码中,找出dom上被绑定的事件,然后进行全埋点。

    无埋点的优点:

    由于采集的是全量数据,所以产品迭代过程中是不需要关注埋点逻辑的,也不会出现漏埋、误埋等现象
    缺点:

    无埋点采集全量数据,给数据传输和服务器增加压力
    无法灵活的定制各个事件所需要上传的数据
    三、前端埋点方案选型和前端上报方案设计
    第一章中介绍了前端所需要监听的信息,在第二章中介绍了前端埋点的常见方式,本文来根据需求,来定制我们的埋点和上报方案。

    (1)监控数据
    首先我们需要明确一个产品或者网页,普遍需要监控和上报的数据。监控的分为三个阶段:用户进入网页首页、用户在网页内部交互和交互中报错。每一个阶段需要监控和上报的数据如下图所示:

    default
    (2)埋点方案
    在实际项目中考虑到上报数据的灵活定制,以及减少数据传输和服务器的压力,在所需埋点处不多的情况下,常用的方式是代码埋点。

    以用户进入首页为例,我们在首页渲染完成后会发送事件类型和类型相关的数据给server端,告知首页的监控信息。

    default
    (3)上报周期和上报数据类型
    如果埋点的事件不是很多,上报可以时时进行,比如监控用户的交互事件,可以在用户触发事件后,立刻上报用户所触发的事件类型。如果埋点的事件较多,或者说网页内部交互频繁,可以通过本地存储的方式先缓存上报信息,然后定期上报。

    接着来确定需要埋点上报的数据,上报的信息包括用户个人信息以及用户行为,主要数据可以分为:

    who: appid(系统或者应用的id),userAgent(用户的系统、网络等信息)

    when: timestamp(上报的时间戳)

    from where: currentUrl(用户当前url),fromUrl(从哪一个页面跳转到当前页面),type(上报的事件类型),element(触发上报事件的元素)

    what: 上报的自定义扩展数据data:{},扩展数据中可以按需求定制,比如包含uid等信息

    上报数据的对象为:

    {   
        ----------------上报接口本身提供--------------------
        currentUrl,  
        fromUrl,
        timestamp,
        userAgent:{
           os,
           netWord,
        }
        ----------------业务代码配置和自定义上报数据------------
        type,
        appid,
        element,
        data:{
            uid,
            uname
        }
    }
    

    (4)埋点和上报举例
    我们以上报首屏加载事件为例,DOM提供了document的DOMContentLoaded事件来监听dom挂载,提供了window的load事件来监听页面所有资源加载渲染完毕。

    (5)前端埋点系统的前后端通信加密
    在上报数据的前后端通信中,需要和server端协商加密机制,利用 OpenSSL库来实现的加密,OpenSSL已经是一个广泛被采用的加密算法。前端可以采用node的crypto模块。

    首先来看hash算法,crypto.createHash() 来创建一个Hash实例,可利用的hash算法如下:

    md5

    sha1

    sha256

    sha512

    ripemd160

    以sha256算法加密为例:

    const str=“123445”;//需要加密的字段
    const hash=crypto.createHash(‘sha256’);//指定加密算法
    hash.update(str); //通过算法加密相应的字段
    const result=hash.digest(‘hex’);//转化成十六进制
    复制代码
    四、前端监控结果可视化展示系统的设计
    当后端得到前端上报的信息之后,经过数据分析和处理,需要前端可视化的展示数据分析后的结果。

    可以在开源中后台系统ant-design-pro的基础上进行二次开发,首先要明确展示信息。展示的信息包括单个用户和整体应用。

    对于单个用户来说需要展示的监控信息为:

    单个用户,在交互过程中触发各个埋点事件的次数
    单个用户,在某个时间周期内,访问本网页的入口来源
    单个用户,在每一个子页面的停留时间
    对于全体用户需要展示的信息为:

    某一个时间段内网页的PV和UV
    全体用户访问网页的设备和操作系统分析
    某一个时间段内访问本网页的入口来源分析
    全体用户在访问本网页时,在交互过程中触发各个埋点事件的总次数
    全体用户在访问本网页时,网页上报异常的集合
    删选功能集合:

    时间筛选:提供今日(00点到当前时间)、本周、本月和全年
    用户删选:提供根据用户id删选出用户行为的统计信息
    设备删选:删选不同系统的整体展示信息

    更多相关内容
  • 修复 Checkbox 无 disabled 样式问题 (#1414)amis前端代码框架是一个低代码前端框架,它使用 JSON 配置来生成页面,可以节省页面开发工作量,极大提升开发前端页面的效率。 目前在百度广泛用于内部平台的前端开发...
  • 前端页面跳转

    千次阅读 2022-03-30 16:10:11
    C页面刷新 (也可以使用子窗口的 opener 对象来获得父窗口的对象: window.opener.document.location.reload()) “top.location.reload()”: A页面刷新 5、window.location.replace和window.location.href区别 当在...

    前端页面跳转、刷新

    一、location.href的用法

    let url = "www.baidu.com";
    

    1、当前页面打开url页面

    self.location.href="url";
    // 等同于
    this.location.href="url";
    window.location.href="url";
    location.href="url"; 
    

    2、在父窗口打开此url窗口

    parent.location.href="url";
    

    3、在顶层页面打开url(跳出框架)

    top.location.href="url";
    

    4、附1:刷新当前页面

    • Ⅰ、window.location.href=window.location.href有提交数据时,则是向指定的url提交数据
    • Ⅱ、window.location.Reload(),有提交数据时,会提示是否提交
    • Ⅲ、window.location.replace()可以导向另外一个URL

    案例说明:

    如果A,B,C,D都是jsp,D是C的iframe,C是B的iframe,B是A的iframe

    D中的js:

    window.location.href”、“location.href”:D页面跳转
    parent.location.href”:C页面跳转
    top.location.href”:A页面跳转

    D页面中有form:

    <form>: form提交后D页面跳转
    <form target="_blank">: form提交后弹出新页面
    <form target="_parent">: form提交后C页面跳转
    <form target="_top"> : form提交后A页面跳转
    

    页面刷新,D 页面:

    parent.location.reload()”: C页面刷新 (也可以使用子窗口的 opener 对象来获得父窗口的对象: window.opener.document.location.reload()

    top.location.reload()”: A页面刷新

    5、window.location.replace和window.location.href区别

    当在微信公总号中 点击手机系统自带的默认返回按钮时:页面直接退出了公众号而不是返回到上一页, 是因为,跳转当前页的时候没有记录历史路由,用的是window.location.replace,而不是window.location.href或者vue-router

    有3个页面 a,b,c,如果当前页面是c页面,并且c页面是这样跳转过来的:a->b->c

    • Ⅰ:b->c 是通过window.location.replace(“…xx/c”) 此时b页面的url会被c页面代替,并且点击后退按钮时会回退到a页面(最开始的页面)可以用来刷新页面
    • Ⅱ:b->c是通过window.location.href(“…xx/c”) 此时b页面的路径会被c页面代替,但是点击回按钮后页面回退的是b页面

    两者的区别: 两者后退时所回退的页面不一样

    6、附2:自动刷新(HTML实现)

    页面自动刷新:把如下代码加入<head>区域中

    <!-- 2指每隔2秒刷新一次页面 -->
    `<meta http-equiv="refresh" content="2">`
    

    页面自动跳转:把如下代码加入<head>区域中

    <!-- 2指隔2秒后跳转到`http://www.baidu.com`页面 -->
    `<meta http-equiv="refresh" content="2;url=http://www.baidu.com">`
    

    二、window.open的用法

    1、语法:

    window.open(strUrl, strWindowName, [strWindowFeatures])

    strUrl:要在新打开的窗口中加载的URL。

    strWindowName:新窗口的名称。

    可选的参数如下

    • _blank :打开一个新的标签页。这个是默认值
    • _parent :父页面打开
    • _self :当期页面打开
    • _top :顶层页面打开
    • name:窗口名称

    strWindowFeatures:这是一个可选参数,列出新窗口的特征。

    2、Location.href属性与window.open()方法的区别:

    • Location.href属性是对当前浏览器窗口的URL地址对象的参考;window.open()方法打开一个新的窗口。
    • Location.href属性一般用于页面的迭代,也就是重新定位当前页
    • window.open()方法可以通过新开窗口或者说新开标签页打开一个网址,而location.href属性只能在当前页打开一个网址。

    3、附:返回页面

    window.history.back(); // 返回到上一页(在当前窗口 )
    window.history.go(-1);
    

    三、navigate

    【说明】:navigate的效果是在当前页面直接跳转至指定路由,当前页面会被覆盖掉,而且不会对跳转后的页面数据进行刷新,也就是说,跳转后的页面显示的还是旧数据。

    假设指定需要跳转的目标路由是“/class/student”。

    this.router.navigate(['/class/student'])
    

    四、document.getElementById(“a标签id”).click();

    【说明】:这种方式的效果是执行代码自动触发html中id为openStudent的a标签中的链接,进而跳转进入指定页面,这样就不用手动点击a标签的链接进入指定页面。

    假设指定需要跳转的目标路由是“/class/student”。

    document.getElementById("openStudent").click();
    

    五、routerLink

    【说明】:a标签中使用[routerLink],手动点击a标签中的链接,[routerLink]的效果是另外打开一个页面,在新页面中进入指定路由“/class/student”并且会刷新页面数据,而不是在当前页面直接跳转至指定路由,如果路由“/class/student”已经在其他页面打开,那么[routerLink]会直接跳转至路由“/class/student”对应的页面,但不会刷新页面数据。

    假设指定需要跳转的目标路由是“/class/student”。

    <a class="btn " appClick [target]='"blank"' [routerLink]='/class/student' ><span id="openStudent">进入学生信息界面</span></a>
    

    routerLink的几种写法:

    • (1).[routerLink]=‘/class/student’:斜杠开头表示使用绝对路径进行路由导航;
    • (2).[routerLink]=‘…/student’:两个点开头表示相对于父路径进行路由导航;
    • (3).[routerLink]=‘./student’:一个点开头表示相对于当前路径进行路由导航。
    展开全文
  • 前端代码审查工具If you are part of a front-end team with several talents (including you), hundreds of commit might be pushed every day. Indeed, no matter the team methodology you use to deliver new ...

    前端代码审查工具

    If you are part of a front-end team with several talents (including you), hundreds of commit might be pushed every day. Indeed, no matter the team methodology you use to deliver new features, each developer is working on a specific functionality.

    如果您是拥有多个才华(包括您)的前端团队的一员,那么每天可能会推动数百次提交。 的确,无论您使用什么团队方法来交付新功能,每个开发人员都在致力于特定的功能。

    In order to validate their changes, a developer should ask for a Merge Request (or Pull Request) to merge these changes into the common branch (the one used for reference). Other front-end developers will make a code review.

    为了验证其更改,开发人员应请求合并请求(或请求请求)以将这些更改合并到公共分支(用于参考的分支)中。 其他前端开发人员将进行代码审查。

    A code review is important for four reasons:

    代码审查很重要,原因有四个:

    • You can check if the code fulfills the specifications.

      您可以检查代码是否符合规范。
    • You are informed about the code modifications, which will potentially lead you to change your modifications on your active branch or suggest some enhancements.

      您将获得有关代码修改的信息,这可能会导致您在活动分支上更改您的修改或提出一些增强建议。
    • It’s a good practice to guarantee a quality code.

      保证质量代码是一个好习惯。
    • It’s a way to share experiences, tips, and coding skills.

      这是一种分享经验,技巧和编码技能的方法。

    Let’s see together what you should inspect in your next front-end code review.

    让我们一起看看在下一个前端代码审查中应检查的内容。

    An image representing a code review colors for changes
    Image source: Author
    图片来源:作者

    To review code changes, we will focus on five main topics:

    为了查看代码更改,我们将重点关注五个主要主题:

    • The quality of the code

      代码质量
    • Efficiency and robustness of the code

      代码的效率和健壮性
    • Are JS framework principles respected?

      是否遵守JS框架原则?
    • GitFlow principles

      GitFlow原理
    • Accessibility (a11y) and internationalization (i18n)

      可访问性(a11y)和国际化(i18n)

    代码质量 (The Quality of the Code)

    The quality level of source code is always difficult to evaluate, especially when it involves several files and, at a broader level, an entire application.

    源代码的质量级别始终很难评估,尤其是当它涉及多个文件,更广泛地说,涉及整个应用程序时。

    Anyway, good code must follow general software development principles, no matter the language. Here are some of them.

    无论如何,良好的代码必须遵循通用的软件开发原则,无论使用哪种语言。 这里是其中的一些。

    DRY和代码分解 (DRY and code factoring)

    If we were asked for the first coding rule in software development that comes into our mind, we surely answer DRY, Don’t Repeat Yourself. It’s a key principle to avoid code redundancy.

    如果我们被问到我们想到的软件开发中的第一个编码规则,我们肯定会回答DRY,不要重复自己。 这是避免代码冗余的关键原则。

    Finding code duplication consists of inspecting the source code and spotting pieces of code that are repeated several times throughout a file or a bunch of files. It may take the form of a constant value, statements, or a set of static values.

    查找代码重复项包括检查源代码并找出在一个文件或一堆文件中重复几次的代码段。 它可以采用常量值,语句或一组静态值的形式。

    Then you can suggest to factor these lines of code with a new file containing static values or helpers/util functions that will be accessible anywhere in the project.

    然后,您可以建议使用一个新文件将这些代码行分解为一个新文件,其中包含可在项目中的任何位置访问的静态值或辅助函数/实用函数。

    Leveraging Javascript Framework’s techniques and features you use is a good habit. Whether you use Angular, React, or Vue.js, each one of them provides tools to factor pieces of code. You should check if a method can be reused as:

    利用Javascript Framework的技术和功能是一个好习惯。 无论您使用Angular,React还是Vue.js,它们中的每一个都提供工具来分解代码段。 您应该检查方法是否可以按以下方式重用:

    In addition, repeated templates can be extracted into a dedicated component or a fragment (if using React) to be reused as much as necessary. This follows the rule of component specialization from React.

    此外,可以将重复的模板提取到专用组件或片段 (如果使用React)中,以根据需要进行重用。 这遵循了React的组件专门化规则。

    有意义的评论 (Meaningful comments)

    Clean code is self-explanatory.

    干净的代码是不言自明的。

    That is why clean code should not contain comments. Variable and method names should be super explicit. In such circumstances, reading code could be similar to reading a book — but that’s not always the case.

    这就是为什么干净的代码不应包含注释。 变量名和方法名应该是超级明确的。 在这种情况下,阅读代码可能类似于阅读书本-并非总是如此。

    Let’s be honest. Every project has its own specificities that should be commented. Meaningful comments are welcome to explain what is going on. But what is a meaningful comment?

    说实话。 每个项目都有其自身的特点,应加以评论。 欢迎发表有意义的评论,以解释正在发生的事情。 但是什么是有意义的评论?

    It should be written over two lines. The first one explains the situation (why do we do what we do). Then the second one indicates the action to face the issue. For example, let’s assume we have to authenticate automatically a user:

    它应该写在两行上。 第一个解释了这种情况(为什么要做我们所做的事情)。 然后第二个指示指出要解决该问题的措施。 例如,假设我们必须自动认证用户:

    // If a network error occurred because no cookie
    // Login again with JWT (JSON Web Token)
    if (err.message.includes('Missing Session token') && jwt) {
    await loginUser(jwt);
    doSomethingElse();
    }

    Plus, seek for commented codes and suppress them! Indeed, it’s a common habit to comment a piece of code to activate it later or to avoid losing it. Frankly, it’s useful 10% of the time, so you can suggest erasing them without a doubt. If they are necessary later, you could refer to the Git history to retrieve the snippet. Deleting these comments will save you time when scrolling and will avoid irrelevant code in files.

    另外,寻找注释的代码并压制它们! 确实,注释一段代码以稍后激活或避免丢失代码是一个普遍的习惯。 坦白地说,它在10%的时间内都是有用的,因此您可以毫无疑问地建议擦除它们。 如果以后需要使用它们,则可以参考Git历史记录来检索代码段。 删除这些注释将为您节省滚动时间,并避免文件中不相关的代码。

    聪明的样式表 (A clever stylesheet)

    CSS is not just a set of rules to give a color to a block of content or to lay out div in the DOM. It comes with some strategies that must be followed in every component of your project.

    CSS不仅仅是一组为内容块添加颜色或在DOM中布置div的规则。 它带有一些必须在项目的每个组件中遵循的策略。

    A clear CSS structure must be set in every template with explicit and meaningful class names. Check if stateful names are used, as an example:

    必须在每个模板中使用明确且有意义的类名称设置清晰CSS结构。 例如,检查是否使用有状态名称:

    <div class="phone-field--is-error">For input with error</div>
    <div class="phone-field--is-success">For input with valid value</div>

    New stylesheet languages such as Sass, Less, and Stylus allow you to create reusable CSS classes, thanks to classes’ combination, variables, and mixins. Using their superpowers will save you time and reduce efforts. Then checking for CSS improvements is a good bet to make reusable layout and appearance for components.

    借助SassLessStylus等新的样式表语言,您可以创建可重用CSS类,这要归功于类的组合,变量和mixins。 利用他们的超能力将节省您的时间并减少工作量。 然后检查CSS的改进是使组件的布局和外观可重用的好选择。

    Another potential check for a clever stylesheet concerns classes’ usage in the template. Indeed, using object syntax for CSS class definition may enhance code readability.

    另一种可能的检查样式表的方法是,在模板中使用类。 实际上,将对象语法用于CSS类定义可以增强代码的可读性。

    Here’s the documentation on object syntax for CSS class definition: Angular, React, Vue.js.

    这是CSS类定义的对象语法文档: AngularReactVue.js

    那单元测试呢? (What about unit tests?)

    We will never stop saying it: A good piece of code is tested with unit tests.

    我们永远不会停止这样说:一段好的代码已经通过单元测试进行了测试。

    These unit tests check every branch the execution could run. It ensures a well-controlled code base and allows you to detect potential regressions quickly when introducing modifications.

    这些单元测试检查执行可以运行的每个分支。 它确保代码库可控,并允许您在引入修改时快速检测潜在的回归。

    Testing is a domain in its own right in computer science. Many key principles from software development should be applied to testing, such as DRY (seen earlier) and KISS (Keep It Stupid and Simple).

    在计算机科学中,测试本身就是一个领域。 软件开发中的许多关键原则应应用于测试,例如DRY(较早见过)和KISS(保持愚蠢而简单)。

    Unit test libraries like Jest, Mocha, Chai, and Jasmine provide plenty of methods to ease unit tests. If you want to extend your test battery with e2e (end-to-end) integration tests, Cypress, with a super friendly and intuitive GUI, is a good bet.

    JestMochaChaiJasmine这样的单元测试库提供了许多简化单元测试的方法。 如果您想通过e2e(端到端)集成测试来扩展测试电池, 赛普拉斯具有超级友好和直观的GUI,是一个不错的选择。

    A basic verification could be to check if a test setup or post-clean statements are not repeated several times. beforeEach and afterEach are appropriate methods to respectively prepare and post-clean the playground (provided by unit testing frameworks).

    一个基本的验证可能是检查测试设置或清洗后声明是否没有重复几次。 beforeEachafterEach是分别准备和清理操场的适当方法(由单元测试框架提供)。

    Test naming has also its importance. A good practice regarding naming is to select one of the following techniques, and stick to it:

    测试命名也很重要。 有关命名的一个好的实践是选择以下技术之一并坚持使用:

    it('SHOULD do something WHEN myVariable is true')# ORmyMethod_SHOULD_return_true_WHEN_myVariable_is_true()

    守则的效率和稳健性 (Efficiency and Robustness of the Code)

    Efficiency and robustness of the code are the main keys to getting a well-controlled and bug-free code base. It’s based on the coding habits and skills of developers, which come with experience.

    代码的效率和健壮性是获得可控且无错误的代码库的主要关键。 它基于开发人员的编码习惯和技能,并附带经验。

    处理意外值 (Handle unexpected values)

    Even though you are 101% sure that a value will always be defined or have an expected value, this won’t be the case at some point in your project. Indeed, projects and applications evolve, and some unexpected values might appear.

    即使您101%确信将始终定义值或具有期望值,但在项目中的某些时候情况并非如此。 实际上,项目和应用程序会不断发展,并且可能会出现一些意想不到的价值。

    That is why it’s important to prevent these situations from happening by doing the following:

    因此,通过执行以下操作来防止发生这些情况很重要:

    • Check for null or undefined values in object properties. If you’re using Typescript or Babel’s optional chaining, it’s super easy with ? syntax.

      检查对象属性中的nullundefined值。 如果您使用的是TypescriptBabel的可选链接 ,那么使用超级简单? 句法。

    • Ensure a default case is provided when using the switch-case statements to handle unexpected values.

      使用switch-case语句处理意外值时,请确保提供了default大小写。

    • Do the same as above for the if — else if — else conditional instructions.

      对于if — else if — else有条件的指令,请执行与上述相同的操作。

    使条件语句清晰易读 (Make conditional statements clear and readable)

    Efficient verification and a clear logic in the conditional instructions will help make for readable code.

    有效的验证和条件指令中清晰的逻辑将有助于使代码更易读。

    Then, ensure there is a rational and logical way in conditions. Maybe the verification is too complicated, maybe it’s not enough safe…

    然后,确保条件中存在合理和逻辑的方式。 验证可能太复杂了,也许不够安全……

    Suggest the creation of a dedicated method to make the condition more readable. Plus, it could be reused elsewhere.

    建议创建专用方法以使条件更易读。 另外,它可以在其他地方重用。

    分解组件 (Factorizing components)

    It’s quite common to find similar templates in several components or in a single component template. A good practice is to extract this code into a specialized component or a reusable template.

    在多个组件或单个组件模板中找到相似的模板是很常见的。 一个好的做法是将这些代码提取到专门的组件或可重用的模板中。

    Angular provides ng-template or ng-container elements to create reusable templates.

    Angular提供ng-templateng-container元素来创建可重复使用的模板。

    React, by definition, is prone to create new specialized components. If you prefer reusable templates, you can find a way in the article “How to Build Reusable Layouts in React JS.”

    根据定义,React倾向于创建新的专用组件。 如果您喜欢可重用模板,则可以在文章“ 如何在React JS中构建可重用布局 ”中找到一种方法。

    Vue.js does not offer such things, but you could either create a dedicated component or follow the advice of Anthony Gore in his article “Extending Vue Component Templates.”

    Vue.js不提供此类功能,但是您可以创建一个专用组件,也可以遵循Anthony Gore在他的文章“ 扩展Vue组件模板 ”中的建议。

    是否遵守JS框架原则? (Are the JS Framework Principles Respected?)

    JS frameworks are unavoidable now when it deals with creating dynamic and user-friendly web applications. They are a game changer in the front-end development world. Each framework comes with its own principles, rules, and conventions. Thus, you need to check if these standards are respected.

    现在,JS框架在处理创建动态且用户友好的Web应用程序时不可避免。 他们是前端开发世界中的游戏规则改变者。 每个框架都有其自己的原理,规则和约定。 因此,您需要检查这些标准是否得到遵守。

    命名约定 (Naming convention)

    Naming conventions should be respected so that it allows identification of the content of the file’s or variable’s purpose.

    应遵守命名约定,以便可以识别文件或变量用途的内容。

    Here is a non-exhaustive list of checks for each framework:

    这是每个框架检查的非详尽清单:

    Angular (more details here)

    Angular ( 更多详细信息在这里 )

    • filenames are suffixed with component, directive, filter, service or module

      文件名后缀有componentdirectivefilterservicemodule

    • Observable variables starts with a $

      可观察变量以$开头

    • private parameters in class constructor are prefixed with an underscore

      类构造函数中的私有参数以下划线为前缀

    React (more details here and here)

    React ( 此处此处有更多详细信息)

    • Use PascalCase for React components and camelCase for component instances

      将PascalCase用于React组件,将camelCase用于组件实例
    • Avoid using DOM component prop names for different purposes

      避免将DOM组件属性名称用于不同目的

    Vue.js (more details here)

    Vue.js ( 此处有更多详细信息 )

    • Component filename and name are “pascal-cased” (e.g., MyComponent.vue)

      组件的文件名和name是“用小写字母括起来的”(例如, MyComponent.vue )

    • Functions or variables from Vue instance starts with a $ (e.g., this.$route or this.$emit), therefore it’s a good practice not to add custom functions or variables starting with this character.

      Vue实例中的函数或变量以$开头(例如, this.$routethis.$emit ),因此,最好不要以此字符开头添加自定义函数或变量。

    生命周期挂钩,数据流和访问器 (Lifecycle hooks, data flow, and accessors)

    JS frameworks are built according to several lifecycle hooks that rule the component state and behaviour. They need to be used appropriately to avoid unexpected infinite loops or memory leaks.

    JS框架是根据几个生命周期挂钩构建的,这些挂钩决定了组件的状态和行为。 需要适当使用它们以避免意外的无限循环或内存泄漏。

    For example, in Angular, you need to check when using Subscriptions if the beforeDestroy lifecycle hook is unsubscribing all subscriptions by calling the unsubscribe method.

    例如,在Angular中,您需要在使用“ Subscriptions时检查beforeDestroy生命周期挂钩是否通过调用unsubscribe方法取消订阅所有订阅。

    In Vue.js, the beforeRouteEnter guard (or any route guards) should, in the end, call the next method to navigate through. This concerns Angular guards too.

    在Vue.js中, beforeRouteEnter保护(或任何路由保护)最后应调用next方法进行导航。 这也与Angular守卫有关。

    In React, you should check for the usage of componentWillMount and componentWillUpdate lifecycle methods, which are now deprecated because of misunderstanding.

    在React中,您应该检查componentWillMountcomponentWillUpdate生命周期方法的使用情况,由于误解,这些方法现在已过时

    render method is mandatory in a class component. It mustn’t modify component state. Further details may be found here.

    render方法在类组件中是必需的。 它不能修改组件状态。 可以在此处找到更多详细信息

    In Vue.js again, you should check for data property changes in computed, which is a main anti-pattern practice. Computed properties are just meant to be data accessors and not to update values. This could be applied to Angular getters.

    在Vue.js再次,你应该检查data的属性更改computed ,这是一个主要的反模式的实践。 计算属性仅是作为数据访问器,而不是更新值。 这可以应用于Angular getters

    GitFlow原理 (GitFlow Principles)

    If you are not familiar with this term, the GitFlow means the strategy you have set to manage several versions of the same code base. There is a reference branch and many copies of it with their specificities.

    如果您不熟悉此术语,则GitFlow表示您已设置用于管理同一代码库的多个版本的策略。 有一个参考分支,并且有很多分支及其特殊性。

    Common rules must be applied regarding this strategy and must be followed to avoid code loss or conflicts. The GitFlow must be respected in every code review.

    必须对此策略应用通用规则,并且必须遵循这些规则以避免代码丢失或冲突。 在每次代码审查中都必须尊重GitFlow。

    每次提交都不应破坏应用程序 (Every commit shouldn’t break the app)

    This is more advice than a check for the code review. Indeed, every single commit mustn’t introduce building time or runtime errors.

    这比检查代码检查更多的建议。 实际上,每个提交都不得引入构建时间或运行时错误。

    If for any reason you need to roll back to a specific commit and this one fires troubleshoots, it will put a mess in all the source code.

    如果出于某种原因您需要回滚到特定的提交并且此操作引发了故障排除,则会使所有源代码陷入混乱。

    That is why it’s a better way to commit frequently with tiny but controlled and clear changes.

    这就是为什么这是一种更好的方法,可以频繁地进行微小但可控且清晰的更改。

    检查涉及的分支 (Check the involved branches)

    It’s not a surprise that a merge request involves two branches: the one containing changes and the reference branch.

    合并请求涉及两个分支也就不足为奇了:一个分支包含更改和引用分支。

    It’s a good idea to check both of them. Indeed, as we have no restriction on creating branches, a mistake might be easily introduced. This may come from various reasons:

    最好将它们都检查一下。 实际上,由于我们对创建分支没​​有任何限制,因此很容易引入错误。 这可能来自多种原因:

    • wrong reference branch (for example, if there is a sub-branch)

      错误的参考分支(例如,如果有子分支)
    • spelling error

      拼写错误
    • duplicated branch to merge (if a copy of the branch to merge has been created for any reason)

      要合并的分支重复(如果出于任何原因创建了要合并的分支的副本)

    Two good practices to avoid introducing unwanted pieces of code are:

    避免引入不需要的代码段的两种良好做法是:

    • Name the feature branch explicitly by prefixing a ticket number (if you use a ticketing platform such as GitLab, GitHub, JIRA, or Azure DevOps Services)

      通过添加票证编号来明确命名功能分支(如果使用票务平台,如GitLabGitHubJIRAAzure DevOps Services )

      Example:

      例:

      287-add-tracking

      287-add-tracking

    • Merge your reference branch into the branch to merge first. This will help to detect potential errors and conflicts in the local branch. Thus, the reference branch is protected and the merge will be controlled.

      将您的参考分支合并到该分支中以首先进行合并。 这将有助于检测本地分支中的潜在错误和冲突。 因此,参考分支受到保护,合并将受到控制。

    在本地测试分支 (Test the branch locally)

    This is a zealous practice but it should be a reflex. Testing the branch locally by checking it out is a nice-to-have habit.

    这是一种热情的做法,但应该是一种反思。 通过检出本地测试分支是一个好习惯。

    Using the simple command git checkout my-feature-branch-to-test and running the app will allow you to detect errors locally when building the app. Of course, it will be a handy way to verify if the specifications have been fulfilled.

    使用简单的命令git checkout my-feature-branch-to-test并运行应用程序,可以使您在构建应用程序时在本地检测错误。 当然,这将是验证规格是否已满足的便捷方法。

    Yet let’s be honest: This costs time, and in a world in which time-to-market must be as short as possible, this practice is often dropped out.

    但说实话:这会浪费时间,而且在这个产品上市时间必须尽可能短的情况下,这种做法经常会被放弃。

    可访问性(a11y)和国际化(i18n) (Accessibility (a11y) and Internationalization (i18n))

    Think broadly! A web app may be visited by a large part of the population, including people from all over the world. Including people with visual, motor, and other impairments by adding a few attributes in your code will change the experience you provide them.

    广泛考虑! Web应用程序可能会被包括世界各地的人在内的大部分人访问。 通过在代码中添加一些属性来包括视觉,运动和其他功能障碍的人,将会改变您为他们提供的体验。

    Accessibility (a11y) and internationalization (i18n) have become key concepts in front-end development. If these features don’t ring a bell with you, you can refer to my previous article “The Front-End Features You Might Have Missed,” User Experience section.

    可访问性(a11y)和国际化(i18n)已成为前端开发中的关键概念。 如果您不满意这些功能,可以参考我以前的文章“ 您可能会错过的前端功能” ,“用户体验”部分。

    辅助功能属性 (Accessibility attributes)

    You should ensure the presence of a11y attributes such as:

    您应确保存在以下所有属性:

    i18n键 (i18n keys)

    A single commit involves many perspectives (including HTML templating, CSS styling, testing, and components), and forgetting a translation may occur — especially when you manage several languages.

    一次提交涉及多个角度(包括HTML模板,CSS样式,测试和组件),并且可能会忘记翻译-尤其是当您管理多种语言时。

    Therefore, do not forget to check if each translation has its match for each language. Plus, a translation may be used in a template but does not correspond to an existing key.

    因此,不要忘记检查每种翻译是否与每种语言相匹配。 另外,翻译可以在模板中使用,但不对应于现有键。

    It seems a boring task, but the devil hides in the details, does it?

    这似乎很无聊,但是魔鬼隐藏在细节中,对吗?

    利用您使用的i18n库 (Leverage the i18n library you use)

    You can do incredible things with your i18n library.

    您可以使用i18n库执行令人难以置信的事情。

    They are getting more and more polyvalent and provide powerful functionalities. You can handle:

    它们越来越多价并提供强大的功能。 您可以处理:

    • Pluralization

      多元化
    • Date and number formatting

      日期和数字格式
    • HTML templating

      HTML模板
    • Translations lazy loading

      翻译延迟加载

    Do not hesitate to over-use it, especially about conjugation (be, is, are, was, were, been), or to add a CSS class on a particular word of a sentence. The goal is to make your translations as much reusable as possible.

    不要犹豫,过度使用它,特别是关于结合( 一直 ),或者对一个句子的特定单词添加CSS类。 目的是使您的翻译尽可能地可重用。

    Leveraging a i18n library will save you time and effort. It’s worth it instead of reinventing the wheel!

    利用i18n库可以节省您的时间和精力。 值得而不是重新发明轮子!

    结论 (To Conclude)

    Reviewing merge requests may take a lot of time, but it’s a good practice to get used to. It allows you to get informed of changes other developers introduce to the code base. In addition, it’s a different way to share programming language tricks, front-end development insights, and experiences.

    审核合并请求可能会花费很多时间,但这是习惯的好习惯。 它使您可以了解其他开发人员对代码库所做的更改。 此外,这是共享编程语言技巧,前端开发见解和经验的另一种方式。

    In the end, the time spent in reviewing will be a good bet for the future since the earlier you set good coding practices, the earlier time spent to review will be shortened. It’s an investment in the future… in some ways.

    最后,花在审查上的时间将是未来的好选择,因为您越早设置好的编码实践,就可以缩短花在审查上的时间越早。 在某些方面,这是对未来的投资。

    翻译自: https://medium.com/better-programming/what-you-should-inspect-in-a-front-end-code-review-4010e1bc285a

    前端代码审查工具

    展开全文
  • 前端代码规范代码提交规范HTML规范CSS规范JavaScript规范注释命名规范运算符其他:Vue 代码规范常规vuex 代码提交规范 每次提交代码时,commit按规范进行备注,如:本次提交新增了新功能:feat: 新增xx功能 code...

    代码提交规范

    每次提交代码时,commit按规范进行备注,如:本次提交新增了新功能:feat: 新增xx功能

    codeinfo
    feat: msg新功能feature
    fix: msg修复bug
    merge: msgmerge
    docs: msg文档修改
    style: msg格式,不影响代码运行的变动
    refactor: msg重构即不是新增功能,也不是修改bug的代码变动
    test: msg增加测试
    chore: msg构建过程或辅助工具的变动
    rm: msg删除文件或代码
    pod: msgpod install / pod update podName

    HTML规范

    1. 普通标签使用小写,外部引入的组件标签使用大写
    <div></div>
    <el-button><el-button>
    <Pagination />
    
    1. 属性的定义,统一使用双引号。
    <input type="text" name="title" />
    
    1. 有下载需求的图片采用 img 标签实现,无下载需求的图片采用 CSS 背景图实现
      产品 logo、用户头像、用户产生的图片等有潜在下载需求的图片,以 img 形式实现,能方便用户下载
      无下载需求的图片,比如:icon、背景、代码使用的图片等,尽可能采用 css 背景图实现

    2. 为图片添加 alt 属性,提高图片加载失败时的用户体验

    <img src="#" alt="这是一张图片" />
    
    1. 为图片添加 width 和 height 属性,以避免页面抖动
    <img src="#" alt="#" width="#" height="#">
    

    CSS规范

    前缀规范

    1. class命名
    • class 必须单词全字母小写,单词间以 - 分隔(例如,.btn 和 .btn-danger)。
    • 避免过度任意的简写。.btn 代表 button,但是 .s 不能表达任何意思。
    • class 名称应当尽可能短,并且意义明确。
    1. CSS命名规范(规则)常用的CSS命名规则
     头:header
     内容:content/container
     尾:footer
     导航:nav
     侧栏:sidebar
     栏目:column
     页面外围控制整体佈局宽度:wrapper
     左右中:left right center
     登录条:loginbar
     标志:logo
     广告:banner
     页面主体:main
     热点:hot
     新闻:news
     下载:download
     子导航:subnav
     菜单:menu
     子菜单:submenu
     搜索:search
     友情链接:friendlink
     页脚:footer
     版权:copyright
     滚动:scroll
     内容:content
     标签:tags
     文章列表:list
     提示信息:msg
     小技巧:tips
     栏目标题:title
     加入:joinus
     指南:guide
     服务:service
     注册:regsiter
     状态:status
     投票:vote
     合作伙伴:partner
    

    JavaScript规范

    注释

    原则

    • As short as possible(如无必要,勿增注释):尽量提高代码本身的清晰性、可读性。
    • As long as necessary(如有必要,尽量详尽):合理的注释、空行排版等,可以让代码更易阅读、更具美感。
      单行注释
      必须独占一行。// 后跟一个空格,缩进与下一行被注释说明的代码一致。
      多行注释
      避免使用 // 这样的多行注释。有多行注释内容时,使用多个单行注释。
      函数/方法注释
    1. 函数/方法注释必须包含函数说明,有参数和返回值时必须使用注释标识。;
    2. 参数和返回值注释必须包含类型信息和说明;
    /**
     * 函数描述
     *
     * @param {string} p1 参数1的说明
     * @param {string} p2 参数2的说明,比较长
     *     那就换行了.
     * @param {number=} p3 参数3的说明(可选)
     * @return {Object} 返回值描述
     */
    function foo(p1, p2, p3) {
        let p3 = p3 || 10;
        return {
            p1: p1,
            p2: p2,
            p3: p3
        };
    }
    

    命名规范

    使用 Camel 命名法。

    运算符

    不要使用约相等运算符,使用=强相等运算符
    同理使用!==

    其他:

    一个请求时,使用.then()

    function request(){
        getDataList().then(res => {
            console.log(res);
        })
    }
    

    多个请求时,使用async/await

    async function request(){
        const res1 = await getDataList1();
        const res2 = await getDataList2();
    }
    

    Vue 代码规范

    常规

    • 当在组件中使用 data 属性的时候 (除了 new Vue 外的任何地方),它的值必须是返回一个对象的函数 data() { return {…} }。
    • prop 的定义应该尽量详细,至少需要指定其类型。
    export default {
        prop: [
            data: {
                type: Array,
                default() {
                    return []
                }
            }
        ]
    }
    
    • 布尔类型的 attribute, 为 true 时直接写属性值。
    • 不要在computed中对vue变量进行操作。
    • 应该优先通过 prop 和事件进行父子组件之间的通信,而不是 this.$parent 或改变 prop。
    • 在组件上总是必须用 key 配合 v-for,以便维护内部组件及其子树的状态。
    • v-if 和 v-for 不能同时使用
    • 公共方法尽量不要挂到原型上, 可以写在 utils 文件,也可以使用 mixin 文件。不要将业务公共组件注册到全局。
    • 不要将任何第三方插件挂载到 vue 原型上。
    • 具有高度通用性的方法,要封装到 libs、全局组件或指令集里。
    • 为组件样式设置作用域。
    • 尽量使用指令缩写。

    vuex

    State (opens new window)为单一状态树,在 state 中需要定义我们所需要管理的数组、对象、字符串等等,只有在这里定义了,在 vue 的组件中才能获取你定义的这个对象的状态。

    • 修改 state 中数据必须通过 mutations。
    • 每一个可能发生改变的 state 必须同步创建一条或多条用来改变它的 mutations。
    • 服务端获取的数据存放在 state 中,作为原始数据保留,不可变动。
      Getters (opens new window)有点类似 vue.js 的计算属性,当我们需要从 store 的 state 中派生出一些状态,那么我们就需要使用 getters,getters 会接收 state 作为第一个参数,而且 getters 的返回值会根据它的依赖被缓存起来,只有 getters 中的依赖值(state 中的某个需要派生状态的值)发生改变的时候才会被重新计算。
    • 通过 getters 处理你需要得到的数据格式,而不是通过修改 state 原始数据。
    • 组件内不强制使用 mapGetters,因为你可能需要使用 getter 和 setter。
    • 改变 state 的唯一方法就是提交 mutations (opens new window)。
    • 组件内使用 mapMutations 辅助函数将组件中的 methods 映射为 store.commit 调用。
    • 命名采用 大写字母 + 下划线 的规则。
    • 定义 CLEAR,以确保路由切换时可以初始化数据。
      Actions
    • 页面重的数据接口尽量在 actions (opens new window)中调用。
    • 服务端返回的数据尽量不作处理,保留原始数据。
    • 获取到的数据必须通过调用 mutations 改变 state。
      Modules
    • 通常情况下按照页面划分 modules (opens new window)。
    • 默认内置了 system 保证了脚手架的基础功能。
    • 每个页面模块或页面的子模块添加属性 namespaced: true。
      文件命名规则
      Component
      所有的Component文件都是以大写开头 (PascalCase),这也是官方所推荐的。
      但除了 index.vue。
      例子:
    • @/components/BackToTop/index.vue
    • @/components/Charts/Line.vue
    • @/views/example/components/Button.vue
      JS 文件
      所有的.js文件都遵循横线连接 (kebab-case)。
      例子:
    • @/utils/open-window.js
    • @/views/svg-icons/require-icons.js
    • @/components/MarkdownEditor/default-options.js
      Views
      在views文件下,代表路由的.vue文件都使用横线连接 (kebab-case),代表路由的文件夹也是使用同样的规则。
      例子:
    • @/views/svg-icons/index.vue
    • @/views/svg-icons/require-icons.js
      使用横线连接 (kebab-case)来命名views主要是出于以下几个考虑。
    • 横线连接 (kebab-case) 也是官方推荐的命名规范之一 文档
    • views下的.vue文件代表的是一个路由,所以它需要和component进行区分(component 都是大写开头)
    • 页面的url 也都是横线连接的,比如https://www.xxx.admin/export-excel,所以路由对应的view应该要保持统一
    • 没有大小写敏感问题
      代码格式化工具
      使用prettier插件进行开发
      代码检测工具
      使用eslint插件进行开发
      安装ESlint插件

    安装并配置完成 ESLint 后,我们继续回到 VSCode 进行扩展设置,依次点击 文件 > 首选项 > 设置 打开 VSCode 配置文件,添加如下配置

    {
      "files.autoSave": "off",
      "eslint.validate": [
        "javascript",
        "javascriptreact",
        "vue-html",
        {
          "language": "vue",
          "autoFix": true
        }
      ],
      "eslint.run": "onSave",
      "eslint.autoFixOnSave": true
    }
    
    展开全文
  • 今天小编就为大家分享一篇json获取数据库的信息在前端页面显示方法,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
  • 如何部署前端代码

    2019-05-22 11:11:54
    《如何部署前端代码》 一。背景介绍 现在的项目一般都是前后端分离,前端的代码是单独部署在服务器上的,那么今天我们就简单的介绍一下部署代码的时候需要注意什么,如何才能让我们的网站性能得到优化 二。...
  • WEB前端开发练习代码

    2022-01-11 23:18:06
    <!DOCTYPE html> <!-- HTML5申明 --> <html lang="zh"> <!-- 表示本网站为中文网站 --> <!-- 头部,定义网页标题和字体样式等 -->...Web前端开发技术初步应用</title> &l.
  • 前端代码调研与总结

    万次阅读 2022-01-21 14:47:48
    近些年来,低代码的概念逐渐流行了起来,而低代码...就应用领域来讲已经很广泛了,例如营销领域,各种页面生产工具,非冰,乐高,宜搭,鲁班。还有电商类的公司都会给商家提供一个类似店铺装修的工具,小程序生产工具
  • 一般开发采用前后端分离,前端代码在本地调试没有问题后,这时候需要将其部署到服务器上,这样就可以随时随地使用网址(或域名,域名得备案申请)来进入网站了,我们来使用Nginx来部署前端代码。 前提: 已经拿到...
  • 前端SEO代码规范 什么是SEO? 搜索引擎优化是一种利用搜索引擎的搜索规则来提高目前网站在有关搜索引擎内的自然排名的方式。SEO是指为了从搜索引擎中获得更多的免费流量,从网站结构、内容建设方案、用户互动传播、...
  • 在这充满网络促销活动的几个月,倍感压力的,除了你的口袋,是否还有程序员的发量呢?每年的双十一、双十二购物狂欢节,各大电商平台都会上线让消费者充满购买欲望的活动页面,而这些活动页面大多都是静...
  • 前端代码是怎样智能生成的?

    千次阅读 2020-02-17 10:14:37
    在此期间研发小组经历了许多困难与思考,本次 《前端代码是怎样智能生成的》 系列分享,将与大家分享前端智能化项目中技术与思考的点点滴滴。 作者|莱斯 出品|阿里巴巴新零售淘系技术部 概...
  • Web前端JS代码需要保护吗? 这得具体情况具体分析。 1、如果只是写一段web页面图片轮播,或是跑马灯效果等等之类简单的功能。那不需要保护。 2、如果是精心设计一个绚丽的特效,如果想要保护这段自己付诸幸苦实现...
  • 如何优化前端代码

    千次阅读 2018-10-06 18:00:14
    HTTP协议是前端性能乃至安全中一个非常重要的话题,最近在看《web性能权威指南(High Performance Browser Networking)》,把其中关于HTTP部分的内容拿出来分享一下,加了一点自己的想法,当然没有《HTTP权威指南》讲...
  • 前端网页模板

    2018-03-21 10:18:29
    模板引擎有很多,比较知名的在各回答里也都提及了,而我要说的是一个更根本的问题,怎么样的模板引擎是适合前端的首先说明一点,underscore.template这种东西不...商业转载请联系作者获得授权,非商业转载请注明出处。
  • 开源 | 携程 Foxpage 前端代码框架

    千次阅读 2022-02-25 00:01:56
    作者简介Jason Wang,携程研发经理,目前主要负责低代码类产品的设计和研发,关注低代码行业的发展及相关解决方案在企业内部的落地。一、背景随着低代码开发方式被越来越多的人接受和认可,...
  • 前端代码的部署和缓存

    千次阅读 2018-05-31 20:14:20
    Apache中,ETag的值,默认是对文件的索引节(INode),大小(Size)和最后修改时间(MTime)进行Hash后得到的。 If-None-Match:当资源过期时(使用 Cache -Control标识的 max -age),发现资源具有Etage声明,则...
  • 前端代码拆分

    2018-10-12 09:01:11
    问题场景: 在使用前端框架构建单页应用时,服务器会返回一份html文件、抽取出来的css...打包后的js文件包括了框架和依赖库(react、react-router等)还有业务逻辑代码,所以功能越复杂,体积很大。 问题原因分析: ...
  • 前端代码规范(1)谈code review

    千次阅读 2020-09-13 15:42:06
    前端谈code review 一、review代码的认知 1、code review目的 保证代码可读性,一致性 代码层面减少bug,最基本缺少控制判断、异常处理 传播知识+设计讨论。 相信很多人第一次提交 Code Review 都有...
  • 前台用 form 表单的形式提交数据,后台通过 res.render(用的ejs) 可以正常渲染前端页面,后台代码如下:router.post('/classifyadd',(req,res)=>{let{classifyname}=req.body;Classify.create({name:...
  • 目录Smarty概念安装Smarty使用Smarty项目环境初始化编写代码,实现前端页面与php代码分类运行结果 Smarty概念 Smarty是一个使用PHP写出来的模板引擎,是业界最著名的PHP模板引擎之一。它分离了逻辑代码和外在的内容...
  • 大家好,我是你们的 前端章鱼猫,一个不喜欢吃鱼、又不喜欢喵 的超级猫 ~简介前端章鱼猫从 2016 年加入 GitHub,到现在的 2020 年,快整整 5 个年头了。相信很多人都没有逛...
  • HTML代码实现简易购物车-web前端教程

    千次阅读 2020-07-04 17:08:20
    第一步:首先是进行html页面的设计,我用一个大的p将所有商品包含,然后用不同的p将不同的商品进行封装,商品列表中我用了ul li实现,具体实现代码如下(代码中涉及到的商品都是网上随便copy的,不具有参考价值): ...
  • 前端代码规范(静态检查)工具

    万次阅读 2016-06-07 18:57:20
    CSSLint官网:http://csslint.netCSSLint是一个用来帮你找出CSS代码中问题的工具,它可做基本的语法检查以及使用一套预设的规则来检查代码中的问题,规则是...使用方法:进入官网首页,粘贴你的代码,你的错误和不正
  • JavaScript 是脚本语言,是一种解释性脚本语言(代码不进行预编译)
  • 如何保障前端项目的代码质量

    千次阅读 2018-09-10 11:05:49
    对于中大型前端项目,项目规范与代码质量尤为重要。当功能需求变更或需要重构时,随心所欲的(糟糕的)代码可能带来比重新开发还麻烦的问题。 1 前端项目代码中的常见问题 1.1 凌乱的书写风格,阅读体验差 这个问题...
  • 最近在学习前端的性能优化,有必要了解一下页面的渲染流程,以便对症下药,找出性能的瓶颈所在。以下是我看到的一些东西,分享给大家。 参考:Understanding the renderer 页面的渲染有以下特点: •单线程事件轮询 ...
  • 前端 该项目是使用版本10.0.3生成的。 开发服务器 为开发服务器运行ng serve 。 导航到http://localhost:4200/ 。 如果您更改任何源文件,该应用程序将自动重新加载。 代码脚手架 运行ng generate component ...
  • 谷歌浏览器: 1.按F12 –> Network –> Doc –> 看Name里面的请求 –> 得到URL 2.Ctrl+H –> 选择File ... File name patterns中填入web.xml或.java或.jsp找相应的后端代码或前端代码 (注:不要填*,因为可能找不全)

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 184,743
精华内容 73,897
关键字:

怎么得到页面的前端代码