一些前端问题的总结

本篇内容主要讲解“一些前端问题的总结”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“一些前端问题的总结”吧!

站在用户的角度思考问题,与客户深入沟通,找到路南网站设计与路南网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:成都网站建设、网站建设、企业官网、英文网站、手机端网站、网站推广、域名注册、网络空间、企业邮箱。业务覆盖路南地区。

代码逻辑错误

「 人很容易发现别人的错误,而对自己的错误视而不见  」

要想发现代码逻辑的问题,最简单的办法就是看老代码或者看别人的代码。代码逻辑体现的是你对需求的理解,以及你对整个产品逻辑的把控。

比如一个列表的渲染。每一次请求我们都会标记返回的数据列表,记作now_list,然后把列表拼接到现有的列表上面,记作list。当列表底部到页面底部的距离大于一定数值的时候会自动触发请求,加载loading。然后判断当now_list为空的时候,停止自动触发。这是正常的逻辑。

接下来,骚操作来了,把loading的开启条件放在了触发条件里,我们可以记作这个触发的方法为onEndReached,把关闭loading的方法放在了请求方法里。这样导致的结果就是当起始数据量小(比如列表长度为1的时候)的情况下,会不断触发loading,关闭loading,然后进入死循环。然后又一个骚操作来了,因为每次请求的列表数量为4,所以在onEndReached方法里,添加里一个判断条件,当now_list的长度小于4的时候,不开启loading。很简单的问题绕了一个大圈。而且像这种以数字为条件的的代码逻辑,一定要引起警惕。因为这预示着你的代码逻辑不严谨。关于代码逻辑的问题还有多层判断条件的问题,比如报告的生成与查看,查看报告的按钮除了不能在状态1和8展示,其余状态都可以展示;而下载报告的按钮只能在状态5或6展示,分享报告的按钮只能在6展示。无论查看、下载、分享都操作的是同一个按钮。像这种逻辑判断条件多的情况,极易产生错误。

产品需求的错误

「 需求评审,都是一场辩论会,不是说服别人就是被说服 」不要太相信产品,因为他们也会犯错误。总结了一下已知产品需求的错误,分两类:

  • 无用的需求

  • 不合理的需求

先说一下无用的需求,为什么说是无用的,比如上一版做的功能,下一版全部推翻。也就是说,在上一段时间内,你在做无用功,没有对产品产生任何价值。一群人白白耗费了一段时间去做了一件毫无意义的事情。再讲一下不合理的需求,比如买一赠N,在列表中折叠。不管是赠送的订单还是正常的订单,在订单列表中是平铺的。为了解决订单之间的关联关系,给用户呈现层级的展示效果,前端需要做的是把平铺的数据整合成树状结构,然后折叠起来,方便用户查看。列表请求数据条数是一定的,比如4条数据就可以填满屏幕,我们一般会请求5条,以便上拉加载。那么我们可以假设一下场景,比如买一赠7,当我们首先加载完5条数据,并整合成树状结构,折叠起来就变成了一条数据,就会再次触发请求加载,这次我们又加载了5条,不巧的是下一次的正常订单也是买一赠7,前3条数据还是上一条的赠送单,那么我们继续重组数据,现在订单中有两条数据,第一条数据折叠了7条,第二条数据折叠了一条,还会继续触发请求加载,直到屏幕上放满了正常的订单。这个过程会不断的重组数据,并不断的加载loading,关闭loading。专业点的术语可以叫"闪屏"。当然可以把折叠的数据默认展开,这也不失为一个好方法。我承认我们做的一些需求不一定合乎规范,并确实解决了一些问题。但是后期的维护实在太困难,而且不可预料。

场景缺失的错误

「 改bug,最忌讳的就是改一处,制造两处 」

场景缺失的问题,也可以简单的归为两类:

  • 同样问题,只改了一处,其他处没有考虑到

  • 关联问题,只改了有问题的地方,后续产生的问题没有考虑到

前端时间的地址问题确实困扰了一段时间,侧面反应了处理问题不严谨,也反应设计之初没有考虑周全。

省市区的问题,会伴随着传值、回显、提交拼接。问题就出现在了拼接。老数据是直接拼接在一起的,中间没有任何特殊标记,而现在的需求是第三方拿到这个数据无法解析。旧有的逻辑有自己的一套解析机制,但也存在一定的问题,不严谨。所以在已经存在问题的基础修改,注定还是会存在问题。最好的解决办法就是推翻重新制定规则。

当我们在解决问题的时候,一定要考虑此处修改的方案是否会对后续逻辑产生影响,尤其是改别人的代码逻辑,很多问题预料不到,推翻重写成本太大,所以在以后写业务代码的时候一定要解耦,堆在一起的代码,看的实在头疼。

异步错误

代码执行的时机一直以来是一个比较严重的问题,比如我们常常发现的,数据已经请求到了,为什么页面没有显示。

比如react中的setState,更新DOM树是一个很耗时的工作,setState会等一个时机做批量的更新,而不是直接更新。

再比如很多同学想在forEach或map中使用async异步函数,但是不要忘了,你接受的结果也是异步的。

概念理解错误

还有一些错误的因为你对事物本身不了解。

比如前几天面试,有一个女孩说「 我刚用vue3写了一个项目 」,那我就问「 那你vue3常用的语法有哪些 」,她的回答「 vue add、vue  ui... 」。我当时脑子就大了。

还有群里哥们问的一个问题:

['1','2','3'].map(parseInt) // [1, null, null] ['1','2','3'].map(Number) // [1, 2, 3] ['1','2DDDD','3'].map(parseFloat) // [1, 2, 3]

问:「 为什么parseInt不可以实现转化 」

map接受方法参数是固定,只能减少,不能修改,parseInt接受的两个参数,第二个参数直接被改成了map规定的索引值,再执行parseInt的逻辑,返回的肯定不对了。

换句简单的理解就是parseInt接受的参数被map强行改为了索引:

parseInt('2',1) // NaN parseInt('3',2) // NaN

到此,相信大家对“一些前端问题的总结”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!


文章题目:一些前端问题的总结
网站网址:http://scyanting.com/article/gppocs.html