共计 2227 个字符，预计需要花费 6 分钟才能阅读完成。
对于前端防御性编程
- 咱们大多数状况可能遇到过，后端的因为同时申请人数过多，或者数据量过大，又或者是因为异样导致服务异样，接口申请失败，而后前端呈现白屏或者报错
- 还有一种状况，是前端本身写的代码存在一些缺点，整个零碎不够强壮，从而会呈现白屏，或者业务零碎异样，用户误操作等
- 那么，就呈现了前端防御性编程
常见的问题和防备
1. 最常见的问题:
uncaught TypeError: Cannot read property 'c' of undefined呈现这个问题最根本原因是：
当咱们初始化一个对象 obj 为 {} 时候,obj.a 这个时候是 undefined. 咱们打印 obj.a 能够失去 undefined, 然而咱们打印 obj.a.c 的时候，就会呈现下面的谬误。js 对象中的未初始化属性值是 undefined, 从 undefined 读取属性就会导致这个谬误(同理，null 也一样)
如何防止?
js 和 ts 目前都呈现了一个 可选链概念, 例如：
const obj = {};
console.log(obj?.b?.c?.d)下面的代码并不会报错，起因是
?.遇到是空值的时候便会返回 undefined.
2. 前端接口层面的谬误机制捕捉
前端的接口调用，个别都比拟频繁，咱们这时候能够思考应用单例模式, 将所有的 axios 申请都用一个函数封装一层。对立能够在这个函数中 catch 捕捉接口调用时候的未知谬误，伪代码如下：
function ajax(url,data,method='get'){const promise = axios[method](url,data)
return promise.then(res=>{}).catch(error){// 对立处理错误}
}
那么只有产生接口调用的未知谬误都会在这里被解决了
3. 谬误边界（Error Boundaries, 前端呈现未知谬误时，展现事后设定的 UI 界面）
以 React 为例
局部 UI 的 JavaScript 谬误不应该导致整个利用解体，为了解决这个问题，React 16 引入了一个新的概念 —— 谬误边界。
谬误边界是一种 React 组件，这种组件能够捕捉并打印产生在其子组件树任何地位的 JavaScript 谬误，并且，它会渲染出备用 UI，而不是渲染那些解体了的子组件树。谬误边界在渲染期间、生命周期办法和整个组件树的构造函数中捕捉谬误。
应用示例：
class ErrorBoundary extends React.Component {constructor(props) {super(props);
this.state = {hasError: false};
}
static getDerivedStateFromError(error) {
// 更新 state 使下一次渲染可能显示降级后的 UI
return {hasError: true};
}
componentDidCatch(error, errorInfo) {
// 你同样能够将谬误日志上报给服务器
logErrorToMyService(error, errorInfo);
}
render() {if (this.state.hasError) {
// 你能够自定义降级后的 UI 并渲染
return <h1>Something went wrong.</h1>;
}
return this.props.children;
}
}留神
-
谬误边界无奈捕捉以下场景中产生的谬误：
- 事件处理（理解更多）
- 异步代码（例如 setTimeout 或 requestAnimationFrame 回调函数）
- 服务端渲染
- 它本身抛出来的谬误（并非它的子组件）
4. 前端简单异步场景导致的谬误
-
这个问题可能远不止这么简略，然而大道至简，遵循单向数据流的形式去扭转数据，例如：
//test.js export const obj = { a:1, b:2 } // 应用 obj import {obj} from './test.js'; obj.a=3;
当你频繁应用这个 obj 对象时，你无奈依据代码去晓得它的扭转程序（即在某个时刻它的值是什么）, 而且这外面可能存在不少异步的代码，当咱们换一种形式，就能晓得它的扭转程序了, 也更不便咱们debug
例如：
//test.js
export const obj = {
a:1,
b:2
}
export function setObj (key,value) {console.log(key,value)
obj[key] = value
}这样，咱们就做到了
5. 前端专一“前端”
- 对于一些敏感数据，例如登录态，鉴权相干的。前端应该是尽量做无感知的转发、携带（这样也不会呈现平安问题）
6. 页面做到可降级
- 对于一些刚上新的业务，或者有存在危险的业务模块，或者会调取不受信赖的接口，例如第三方的接口，这个时候就要做一层降级解决，例如接口调用失败后，剔除对应模块的展现，让用户无感知的应用
7. 巧用 loading 和 disabled
- 用户操作后，要及时 loading 和 disabled 确保不让用户进行反复，避免业务侧呈现 bug
8. 慎用 innerHTML
- 容易呈现安全漏洞，例如接口返回了一段 JavaScript 脚本，那么就会立刻执行。此时脚本如果是歹意的，那么就会呈现不可预知的结果，特地是电商行业，尤其要留神
❤️ 看完三件事
- 如果你感觉这篇内容对你挺有启发，我想邀请你帮我三个小忙：
- 点个「赞」，让更多的人也能看到这篇内容（喜爱不点在看，都是耍流氓 -_-）
- 关注我，让咱们成为长期关系
- 关注公众号「前端巅峰」，继续为你推送精选好文，也能够加我为好友，随时聊骚。
