前言
在实际的项目开发中，需求的不确定往往是令开发工程师最为头疼的事情，即使走完所有的前期准备工作，也很难保证需求100%覆盖所有场景。因此，在开发过程中，也需要我们前端岗位结合自身的开发经验，避免一些交互逻辑上较为基本的错误，让项目功能更为完善。掌握和注意开发中的一些细节问题，也是一个合格的前端开发工程师应具备的基本素养。
表单篇
一、非必填项是否具备删除功能
表单开发是前端开发时最常见的功能之一。必填项为必须填写，表单也会在提交时进行校验。而非必填项为可填可不填，如用户进行了填写，一定要增加删除功能，尤其是下拉输入框时容易忽略此问题。
二、关于图片，输入框，搜索框的限制
在做 上传图片 功能时，应条件反射去明确图片支持哪些格式，图片的大小限制，甚至于图片名称的字符及长度限制，都要进行考虑，并做好充分自验。
在做 输入框 时，应考虑到安全基线，根据输入框的具体功能，对输入框的长度及输入框的字符校验做出针对性的限制。
在做 搜索框 时，要注意搜索框的可输入长度是否小于所搜索字段的最大长度限制，建议一个平台的搜索框统一较长可输入长度能避免不必要的麻烦，如会议白板所有搜索框限制为50字符。
三、使用visible控制表单显隐时，弹窗没有彻底销毁，没有进入beforeDestroy()方法
对一些常用变量进行清空重置时，通常习惯在beforeDestroy方法中进行，但是如果弹窗只是隐藏而没有销毁的话，程序就没有走到beforeDestroy方法中。在会议白板新增人员表单的开发中，出现了打开表单发送请求时，请求参数保留了上一次请求参数的问题，进而引起BUG的产生，也是由于开发经验不足所导致。
建议：在用到beforeDestroy()方法并进行相关操作时，请打断点确保方法是否顺利执行，否则由此引起的BUG很难被察觉。
四、避免重复发送请求问题
在提交表单时，应避免在点击确定按钮后还可继续点击发送请求的问题。element-ui提供了loading属性，可避免重复发送请求的问题。接下来讨论一种更为复杂的情形。
在快速多次点击树节点发送请求查询时，由于上一次请求还没有结束便再次发送请求，会出现多次结果返回的问题。
建议：loading在请求时置为true，在finally()里面置为false，结合loading状态，如果为false表明上一次请求已经完成，点击节点才会再次发送请求，便可很轻松的解决问题，实现类似于防抖的功能。
五、仅展示数据时，标题请用h标签进行包裹
在进行数据的展示时，标题和内容尽量做出区分，使用语义化标签不仅在展示时更为美观，也更利于SEO优化，利于页面布局，代码也更清晰，更利于团队开发和维护。
建议：在UI不能全程跟踪的情况下，前端开发工程师也要承担起部分UI的重任，开发时要注意页面的布局与美观。在开发时也要注意 “：” 等标点符号的国际化处理。
表格篇
一、时间范围组件传空时，后端是否进行了处理
结束时间并没有传值，会传空后端没有处理而报错的问题。在开发时应注意此场景并和后端约定处理。
二、切换状态查询时，页码是否进行了重置
在进行表格开发时，还要注意页码是否重置的问题：
如上图所示，在全部状态下设备较多，切换到第10页查看，显示正常。但是在切换到离线状态时，由于没有将页码的请求参数置为1，导致离线状态有数据，却显示暂无数据的问题。
建议：会议白板多个页面出现此类问题，也是由于开发人员开发经验不足所导致。在开发时要做好充分自验，考虑特殊场景，积累经验。
三、气泡展示是否合理
在表格中使用 :show-overflow-tooltip="true" 这个属性进行悬浮气泡显示时，如气泡字符太长，element-ui也不会换行，进而导致字符太长时气泡拉满整个屏幕的问题。开发时没有输入较长字符，也没有考虑到会出现此问题，进而引进了BUG。
建议：将气泡的样式做全局处理，对宽度做限制，当字符过长时会自动进行换处理，一劳永逸。
其他
一、打开新窗口时不要覆盖原窗口
在进行附件预览时，由于开发经验不足，没有注意使用a标签打开PDF文件时，会覆盖原窗口的问题。
建议：使用a标签时，增加 target="_blank"和 rel="noreferrer" 属性，避免原窗口被覆盖。
二、新功能UI与已存功能风格是否保持一致
涉及到平台端及小程序，小程序开发时会议状态（新开发功能）与平台端（已存功能）的显示颜色不一致而导致易用性问题。注意平台端和小程序相同状态在展示时应保持一致性。
建议：在开发新功能时，新开发菜单页面及相似功能和平台已存功能是否保持一致，不同端的相同变量在展示时是否保持一致，如有不一致及时和UI及产品经理对齐。
