造一个 react-error-boundary 轮子

React中为什么推荐用Axios替代fetch进行HTTP请求 HTTP客户端是前端工程化的核心基础设施,其设计直接影响错误处理、状态管理与可维护性。Axios并非简单封装fetch,而是针对真实业务场景补全了自动JSON解析、统一错误拦截、请求/响应生命周期控制、取消机制与XSRF防护等关键能力。相比原生fetch需手动处理res.json()、status校验、Content-Type序列化及AbortController冗余代码,Axios通过声明式配置和拦截器机制,将网络层抽象为可复用、可监控、可测试的标准化管道。尤其在React生态中,它天然适配async a 阅读详情

以下所有代码都已整理到 Github:https://github.com/Haixiang6123/learn-error-bounday

参考的轮子:https://www.npmjs.com/package/react-error-boundary

发生甚么事了

朋友们好啊,我是海怪,刚才老板对我说:海怪,发生甚么事了,怎么页面白屏了?我说:怎么回事?给我发了几张截图。我打开控制台一看:

哦!原来是昨天,有个后端年轻人,说要和我联调接口,我说:可以。然后,我说:小兄弟,你的数据尽量按我需要的格式来:

interface User {
    name: string;
    age: number;
}

interface GetUserListResponse {
    retcode: number;
    data: User[]
}

踏不服气,他说你这个没用,我说我这个有用,这是规范,传统前后端联调返回数据是要讲规范的,对项目质量的提高可以起到四两拨千斤的作用。100多万行代码的系统,只要有了类型规范,都不会轻易崩溃。他说试试,我说行。

我请求刚发出去,他的数据,啪!的一下就返回了!很快啊!!

{
    retcode: 0,
    data: [
        {name: '张三', age: 11},
        undefined,
        null
    ]
}

上来先是一个 retcode: 0,然后数组里一个 User 对象,一个 undefined,一个 null,我全部用判断 falsy 值防过去了啊:


if (!u) {
   return 0;
}

const trimName = u.name.trim();

return getScore(trimName);

防过去之后自然是正常处理业务逻辑和页面展示。虽然没有按照规范来,但是数组里偶尔有个 falsy 值也还好,我把数组类型改成 Array<string | null | undefined>,没有和他说,同事之间,点到为止。我笑一下提交测试了,发了正式环境,准备收工。然后,这时候,老板突然说线上白屏爆炸,我一看返回的数据:

{
    retcode: 0,
    data: [
        {name: '张三', age: 11},
        '找不到此用户',
        '找不到此用户',
        '找不到此用户'
    ]
}

我大意了啊!没有做类型判断!马上回滚。加了 if (typeof user === 'string') 的字符串类型判断,准备再次发正式,但是我一想不对,难不成对每个数据我都要像像佛一样供着?

// 这就很离谱
try {
    const scores = users.map(u => {
        // 判空
        if (!u) {
            return;
        }

        // 判断错误类型
        if (typeof u === 'string') {
            return;
        }

        // 判断属性是否存在
        if (!u.name) {
            return;
        }

        const trimName = u.name.trim(0);

        return getScore(trimName);
    })

    return scores;
} catch (e) {
    return null;
}

这明显是后端没有对错误进行特殊处理啊,但是作为前端开发就算被后端百般蹂躏,页面也不应该白屏,应该就那个组件报错就好了。我定了定神,决定使出**“闪电五连鞭”**。

34fe-kefmphe1371072.gif

相信大家对JS异常捕获很熟悉了,try-catch 一包业务代码就收工了。不过,在组件里对异常捕获,需要用到的是 React 提供的 Error Boundary 错误边界特性,用 componentDidCatch 钩子来对页面异常进行捕获,以至于不会将异常扩散到整个页面,有效防止页面白屏。

下面,我来展示一下怎么打好这套**“闪电五连鞭”**。

第一鞭:抄

直接把官网例子抄下来,将 ErrorBoundary 组件输出:

class ErrorBoundary extends React.Component {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error) {
    // 更新 state 使下一次渲染能够显示降级后的 UI
    return { hasError: true };
  }

  componentDidCatch(error, errorInfo) {
    // 你同样可以将错误日志上报给服务器
    logger.error(error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      // 你可以自定义降级后的 UI 并渲染
      return <h1>Something went wrong.</h1>;
    }

    return this.props.children; 
  }
}

然后将业务组件包裹:

<ErrorBoundary> // 捕获错误
  <UserList /> // 使劲报错
</ErrorBoundary>

如果 UserList 里报错,ErrorBoundary 就会捕获,然后在 getDerivedStateFromError 里更新组件状态,render 里就会显示 Something went wrong,不会渲染 this.props.children。

总结:
1. 将 ErrorBoundary 包裹可能出错的业务组件
2. 当业务组件报错时,会调用 componentDidCatch 钩子里的逻辑,将 hasError 设置 true,直接展示

第二鞭:造个灵活的轮子

上面只是解决了燃眉之急,如果真要造一个好用的轮子,不应直接写死 return <h1>Something went wrong</h1>,应该添加 props 来传入报错显示内容(以下统称为 fallback):

// 出错后显示的元素类型
type FallbackElement = React.ReactElement<unknown, string | React.FC | typeof React.Component> | null;

// 出错显示组件的 props
export interface FallbackProps {
  error: Error;
}

// 本组件 ErrorBoundary 的 props
interface ErrorBoundaryProps {
  fallback?: FallbackElement;
  onError?: (error: Error, info: string) => void;
}

// 本组件 ErrorBoundary 的 props
interface ErrorBoundaryState {
  error: Error | null; // 将 hasError 的 boolean 改为 Error 类型,提供更丰富的报错信息
}

// 初始状态
const initialState: ErrorBoundaryState = {
  error: null,
}

class ErrorBoundary extends React.Component<React.PropsWithChildren<ErrorBoundaryProps>, ErrorBoundaryState> {
  state = initialState;

  static getDerivedStateFromError(error: Error) {
    return {error};
  }

  componentDidCatch(error: Error, errorInfo: React.ErrorInfo) {
    if (this.props.onError) {
      this.props.onError(error, errorInfo.componentStack);
    }
  }

  render() {
    const {fallback} = this.props;
    const {error} = this.state;

    if (error !== null) {
      if (React.isValidElement(fallback)) {
        return fallback;
      }

      throw new Error('ErrorBoundary 组件需要传入 fallback');
    }

    return this.props.children;
  }
}

export default ErrorBoundary

上面提供 onError 和 falback 两个 props,前者为出错的回调,可以做错误信息上报或者用户提示,后者则传入错误提示内容,像下面这样:

const App = () => {
  return (
    <ErrorBoundary fallback={<div>出错啦</div>} onError={logger.error('出错啦')}>
      <UserList />
    </ErrorBoundary>
  )
}

这已经让 ErrorBoundary 变得稍微灵活一点了。但是有人就喜欢把 fallback 渲染函数、Fallback 组件作为 props 传入 ErrorBoundary,而不传一段 ReactElement,所以为了照顾更多人,将 fallback 进行扩展:

export declare function FallbackRender (props: FallbackProps): FallbackElement;

// 本组件 ErrorBoundary 的 props
interface ErrorBoundaryProps {
  fallback?: FallbackElement; // 一段 ReactElement
  FallbackComponent?: React.ComponentType<FallbackProps>; // Fallback 组件
  fallbackRender?: typeof FallbackRender; // 渲染 fallback 元素的函数
  onError?: (error: Error, info: string) => void;
}

class ErrorBoundary extends React.Component<React.PropsWithChildren<ErrorBoundaryProps>, ErrorBoundaryState> {
  ...

  render() {
    const {fallback, FallbackComponent, fallbackRender} = this.props;
    const {error} = this.state;
    
    // 多种 fallback 的判断
    if (error !== null) {
      const fallbackProps: FallbackProps = {
        error,
      }
      // 判断 fallback 是否为合法的 Element
      if (React.isValidElement(fallback)) {
        return fallback;
      }
      // 判断 render 是否为函数
      if (typeof fallbackRender === 'function') {
        return (fallbackRender as typeof FallbackRender)(fallbackProps);
      }
      // 判断是否存在 FallbackComponent
      if (FallbackComponent) {
        return <FallbackComponent {...fallbackProps} />
      }

      throw new Error('ErrorBoundary 组件需要传入 fallback, fallbackRender, FallbackComponent 其中一个');
    }

    return this.props.children;
  }
}

上面提供 3 种方式来传入出错提示组件: fallback(元素)、FallbackComponent(组件),fallbackRender(render 函数)。现在使用轮子就更灵活了:

const App = () => {
  const onError = () => logger.error('出错啦')
  
  return (
    <div>
      <ErrorBoundary fallback={<div>出错啦</div>} onError={onError}>
        <UserList />
      </ErrorBoundary>
      
      <ErrorBoundary FallbackComponent={ErrorFallback} onError={onError}>
        <UserList />
      </ErrorBoundary>

      <ErrorBoundary
        fallbackRender={(fallbackProps) => <ErrorFallback {...fallbackProps} />}
        onError={onError}
      >
        <UserList />
      </ErrorBoundary> 
    </div>
  )
}

总结一下这里的改动:
1. 将原来的 hasError 转为 error,从 boolean 转为 Error 类型,有利于获得更多的错误信息,上报错误时很有用
2. 添加 fallback, FallbackComponent, fallbackRender 3个 props,提供多种方法来传入展示 fallback

第三鞭:添加重置回调

有时候会遇到这种情况:服务器突然抽风了,503、502了,前端获取不到响应,这时候某个组件报错了,但是过一会又正常了。比较好的方法是允许用户点一下 fallback 里的一个按钮来重新加载出错组件,不需要重刷页面,这样的操作下面称为**“重置”**。

同时,有些开发者也需要在重置里添加自己逻辑,比如弹提示、日志上报等。

图解:

下面给出上面两个需求的实现:

// 出错后显示的元素类型
type FallbackElement = React.ReactElement<unknown, string | React.FC | typeof React.Component> | null;

// 出错显示组件的 props
export interface FallbackProps {
  error: Error;
  resetErrorBoundary: () => void; // fallback 组件里将该函数绑定到“重置”按钮
}

// 本组件 ErrorBoundary 的 props
interface ErrorBoundaryProps {
  ...
  onReset?: () => void; // 开发者自定义重置逻辑,如日志上报、 toast 提示
}

class ErrorBoundary extends React.Component<React.PropsWithChildren<ErrorBoundaryProps>, ErrorBoundaryState> {
  ...
  // 重置该组件状态,将 error 设置 null
  reset = () => {
    this.setState(initialState);
  }

  // 执行自定义重置逻辑,并重置组件状态  
  resetErrorBoundary = () => {
    if (this.props.onReset) {
      this.props.onReset();
    }
    this.reset();
  }

  render() {
    const {fallback, FallbackComponent, fallbackRender} = this.props;
    const {error} = this.state;

    if (error !== null) {
      const fallbackProps: FallbackProps = {
        error,
        resetErrorBoundary: this.resetErrorBoundary,  // 将 resetErrorBoundary 传入 fallback
      }

      if (React.isValidElement(fallback)) {
        return fallback;
      }
      if (typeof fallbackRender === 'function') {
        return (fallbackRender as typeof FallbackRender)(fallbackProps);
      }
      if (FallbackComponent) {
        return <FallbackComponent {...fallbackProps} />
      }

      throw new Error('ErrorBoundary 组件需要传入 fallback, fallbackRender, FallbackComponent 其中一个');
    }

    return this.props.children;
  }
}

改写之后,在业务代码中添加重置逻辑:

const App = () => {
  const onError = () => logger.error('出错啦')
  const onReset = () => {
    console.log('已重置')
    message.info('刚刚出错了,不好意思,现在已经重置好了,请找老板锤这个开发')
  }
  // fallback 组件的渲染函数
  const renderFallback = (props: FallbackProps) => {
    return (
      <div>
        出错啦,你可以<button onClick={props.resetErrorBoundary}>重置</button>
      </div>
    )
  }

  return (
    <div>
      <ErrorBoundary
        fallbackRender={renderFallback}
        onReset={onReset}
        onError={onError}
      >
        <UserList />
      </ErrorBoundary>
    </div>
  )
}

上面例子中,在 onReset 里自定义想要重试的逻辑,然后在 renderFallback 里将 props.resetErrorBoudnary 绑定到重置即可,当点击“重置”时,就会调用 onReset ,同时将 ErrorBoundary 组件状态清空(将 error 设为 null)。

总结:
1. 添加 onReset 来实现重置的逻辑
2. 在 fallback 组件里找个按钮绑定 props.resetErrorBoundary 来触发重置逻辑

第四鞭:监听渲染以重置

上面的重置逻辑简单也很实用,但是有时也会有局限性:触发重置的动作只能在 fallback 里面。假如我的重置按钮不在 fallback 里呢?或者 onReset 函数根本不在这个 App 组件下那怎么办呢?难道要将 onReset 像传家宝一路传到这个 App 再传入 ErrorBoundary 里?

这时,我们就会想:能不能监听状态的更新,只要状态更新就重置,反正就重新加载组件也没什么损失,这里的状态完全用全局状态管理,放到 Redux 中。

上面的思路听起来不就和 useEffect 里的依赖项 deps 数组一样嘛,不妨在 props 提供一个 resetKeys 数组,如果这个数组里的东西变了,ErrorBoundary 就重置,这样一控制是否要重置就更灵活了。马上动手实现一下:

// 本组件 ErrorBoundary 的 props
interface ErrorBoundaryProps {
  ...
  resetKeys?: Array<unknown>;
}

// 检查 resetKeys 是否有变化
const changedArray = (a: Array<unknown> = [], b: Array<unknown> = []) => {
  return a.length !== b.length || a.some((item, index) => !Object.is(item, b[index]));
}

class ErrorBoundary extends React.Component<React.PropsWithChildren<ErrorBoundaryProps>, ErrorBoundaryState> {
  ...

  componentDidUpdate(prevProps: Readonly<React.PropsWithChildren<ErrorBoundaryProps>>) {
    const {error} = this.state;
    const {resetKeys, onResetKeysChange} = this.props;
    
    // 只要 resetKeys 有变化,直接 reset
    if (changedArray(prevProps.resetKeys, resetKeys)) {
      // 重置 ErrorBoundary 状态,并调用 onReset 回调
      this.reset();
    }
  }

  render() {
    ...
  }
}

首先,在 componentDidupdate 里去做 resetKeys 的监听,只要组件有 render 就看看 resetKeys 里面的元素是否改过了,改过了就会重置。

但这里又会有一个问题:万一 resetKeys 里元素是个 Date 或者一个对象怎么办?所以,我们还需要给开发者提供一种判断 resetKeys 元素是否改变的方法,这里就添加一个 onResetKeysChange 的 props 就好了:

// 本组件 ErrorBoundary 的 props
interface ErrorBoundaryProps {
  ...
  resetKeys?: Array<unknown>;
  onResetKeysChange?: (
    prevResetKey: Array<unknown> | undefined,
    resetKeys: Array<unknown> | undefined,
  ) => void;
}

class ErrorBoundary extends React.Component<React.PropsWithChildren<ErrorBoundaryProps>, ErrorBoundaryState> {
  ...

  componentDidUpdate(prevProps: Readonly<React.PropsWithChildren<ErrorBoundaryProps>>) {
    const {resetKeys, onResetKeysChange} = this.props;

    if (changedArray(prevProps.resetKeys, resetKeys)) {
      if (onResetKeysChange) {
        onResetKeysChange(prevProps.resetKeys, resetKeys);
      }

      // 重置 ErrorBoundary 状态,并调用 onReset 回调
      this.reset();
    }
  }

  render() {
    ...
  }
}

在 changedArray 判定后,再次使用 props.onResetKeysChange 再次自定义判断(如果有的话)resetKeys 里的元素值是否有更新。

还有没有问题呢?嗯,还有问题。这里注意这里的 componentDidUpdate 钩子逻辑,假如某个 key 是触发 error 的元凶,那么就有可能触发二次 error 的情况:

  1. xxxKey 触发了 error,组件报错
  2. 组件报错导致 resetKeys 里的一些东西改了
  3. componentDidUpdate 发现 resetKeys 里有东西更新了,不废话,马上重置
  4. 重置完了,显示报错的组件,因为 error 还存在(或者还未解决),报错的组件又再次触发了 error
  5. …

所以要区分出来这一次到底是因为 error 才 render 还是普通组件的 render,而且还需要确保当前有错误才重置,都没错误还重置个毛。具体实现思路如图所示:

实现如下

class ErrorBoundary extends React.Component<React.PropsWithChildren<ErrorBoundaryProps>, ErrorBoundaryState> {
  state = initialState;
  // 是否已经由于 error 而引发的 render/update
  updatedWithError = false;

  static getDerivedStateFromError(error: Error) {
    return {error};
  }

  componentDidCatch(error: Error, errorInfo: React.ErrorInfo) {
    if (this.props.onError) {
      this.props.onError(error, errorInfo.componentStack);
    }
  }
  
  componentDidUpdate(prevProps: Readonly<React.PropsWithChildren<ErrorBoundaryProps>>) {
    const {error} = this.state;
    const {resetKeys, onResetKeysChange} = this.props;
    
    // 已经存在错误,并且是第一次由于 error 而引发的 render/update,那么设置 flag=true,不会重置 
    if (error !== null && !this.updatedWithError) {
      this.updatedWithError = true;
      return;
    }

    // 已经存在错误,并且是普通的组件 render,则检查 resetKeys 是否有改动,改了就重置
    if (error !== null && changedArray(prevProps.resetKeys, resetKeys)) {
      if (onResetKeysChange) {
        onResetKeysChange(prevProps.resetKeys, resetKeys);
      }

      this.reset();
    }
  }

  reset = () => {
    this.updatedWithError = false;
    this.setState(initialState);
  }

  resetErrorBoundary = () => {
    if (this.props.onReset) {
      this.props.onReset();
    }
    this.reset();
  }

  render() {
    ...
  }
}

上面的改动有:

  1. 用 updatedWithError 作为 flag 判断是否已经由于 error 出现而引发的 render/update
  2. 如果当前没有错误,无论如何都不会重置
  3. 每次更新:当前存在错误,且第一次由于 error 出现而引发的 render/update,则设置 updatedWithError = true,不会重置状态
  4. 每次更新:当前存在错误,且如果 updatedWithError 为 true 说明已经由于 error 而更新过了,以后的更新只要 resetKeys 里的东西改了,都会被重置

至此,我们拥有了两种可以实现重置的方式了:

方法触发范围使用场景思想负担
手动调用 resetErrorBoundary一般在 fallback 组件里用户可以在 fallback 里手动点击“重置”实现重置最直接,思想负担较轻
更新 resetKeys哪里都行,范围更广用户可以在报错组件外部重置、resetKeys 里有报错组件依赖的数据、渲染时自动重置间接触发,要思考哪些值放到 resetKeys 里,思想负担较重

总结这一鞭的改动:
1. 添加 resetKeys 和 onResetKeysChange 两个 props,为开发者提供监听值变化而自动重置的功能
2. 在 componentDidUpdate 里,只要不是由于 error 引发的组件渲染或更新,而且 resetKeys 有变化了,那么直接重置组件状态来达到自动重置

这里自动重置还有一个好处:假如是由于网络波动引发的异常,那页面当然会显示 fallback 了,如果用上面直接调用 props.resetErrorBoundary 方法来重置,只要用户不点“重置”按钮,那块地方永远不会被重置。又由于是因为网络波动引发的异常,有可能就那0.001 秒有问题,别的时间又好了,所以如果我们将一些变化频繁的值放到 resetKeys 里就很容易自动触发重置。例如,报错后,其它地方的值变了从而更改了 resetKeys 的元素值就会触发自动重置。对于用户来说,最多只会看到一闪而过的 fallback,然后那块地方又正常了。这样一来,用户也不需要亲自触发重置了。

第五鞭:输出轮子

上面四鞭里,到最后都是 export default ErrorBoundary 将组件输出,如果代理里很多个地方都要 catch error,就有这样很啰嗦的代码:

<div>
  <ErrorBoundary>
    <AAA/>
  </ErrorBoundary>
  <ErrorBoundary>
    <BBB/>
  </ErrorBoundary>
  <ErrorBoundary>
    <CCC/>
  </ErrorBoundary>
  <ErrorBoundary>
    <DDD/>
  </ErrorBoundary>
</div>

要处理这样啰嗦的包裹,可以借鉴 React Router 的 withRouter 函数,我们也可以输出一个高阶函数 withErrorBoundary :

/**
 * with 写法
 * @param Component 业务组件
 * @param errorBoundaryProps error boundary 的 props
 */
function withErrorBoundary<P> (Component: React.ComponentType<P>, errorBoundaryProps: ErrorBoundaryProps): React.ComponentType<P> {
  const Wrapped: React.ComponentType<P> = props => {
    return (
      <ErrorBoundary {...errorBoundaryProps}>
        <Component {...props}/>
      </ErrorBoundary>
    )
  }

  // DevTools 显示的组件名
  const name = Component.displayName ||Component.name || 'Unknown';
  Wrapped.displayName = `withErrorBoundary(${name})`;

  return Wrapped;
}

使用的时候就更简洁了一些了:

// 业务子组件
const User = () => {
  return <div>User</div>
}

// 在业务组件加一层 ErrorBoundary
const UserWithErrorBoundary = withErrorBoundary(User, {
  onError: () => logger.error('出错啦'),
  onReset: () => console.log('已重置')
})

// 业务父组件
const App = () => {
  return (
    <div>
      <UserWithErrorBoundary/>
    </div>
  )
}

其实 withXXX 这种写法还可以写成装饰器,将 @withXXX 放到 class component 上也很方便,但是对于 functional component 就放不了了,有点受限,这里不展开了。

还有没有更好的设计呢?我们观察到只有一些比较“严重的异常”浏览器才会报错,比如开头提到的 TypeError: xxx is not a function。JS 是个动态类型语言,在浏览器里你可以:NaN + 1,可以 NaN.toString(),可以 '1' + 1 都不报任何错误。其实官网也说了,对于一些错误 componenDidCatch 是不能自动捕获的:

不过,这些错误在代码里开发者其实是知道的呀。既然开发者们有办法拿到这些错误,那把错误直接抛出就可以让 ErrorBoundary catch 到了:

  1. 有错误的时候,开发者自己调用 handleError(error) 将错误传入函数中
  2. handleError 将错误 throw new Error(error)
  3. ErrorBoundary 发现有上面抛出的 Error,调用 componentDidCatch 处理错误
  4. …

我来提供一种使用 React Hook 的实现方式:

/**
 * 自定义错误的 handler
 * @param givenError
 */
function useErrorHandler<P=Error>(
  givenError?: P | null | undefined,
): React.Dispatch<React.SetStateAction<P | null>> {
  const [error, setError] = React.useState<P | null>(null);
  if (givenError) throw givenError; // 初始有错误时,直接抛出
  if (error) throw error; // 后来再有错误,也直接抛出
  return setError; // 返回开发者可手动设置错误的钩子
}

使用上面的 hook,对于一些需要自己处理的错误,可以有两种处理方法:

  1. const handleError = useErrorHandler(),然后 handleError(yourError)
  2. useErrorHandler(otherHookError),如果别的 hooks 里有 export error,完全可以直接将这个 error 传入 useErrorHandler,直接处理

比如:

function Greeting() {
  const [greeting, setGreeting] = React.useState(null)
  const handleError = useErrorHandler()

  function handleSubmit(event) {
    event.preventDefault()
    const name = event.target.elements.name.value
    fetchGreeting(name).then(
      newGreeting => setGreeting(newGreeting),
      handleError, // 开发者自己处理错误,将错误抛出
    )
  }

  return greeting ? (
    <div>{greeting}</div>
  ) : (
    <form onSubmit={handleSubmit}>
      <label>Name</label>
      <input id="name" />
      <button type="submit">get a greeting</button>
    </form>
  )
}
// 用 ErrorBoundary 包裹,处理手动抛出的错误
export default withErrorBoundary(Greeting)

或者:

function Greeting() {
  const [name, setName] = React.useState('')
  const {greeting, error} = useGreeting(name)

  // 开发者自己处理错误,将错误抛出
  useErrorHandler(error)

  function handleSubmit(event) {
    event.preventDefault()
    const name = event.target.elements.name.value
    setName(name)
  }

  return greeting ? (
    <div>{greeting}</div>
  ) : (
    <form onSubmit={handleSubmit}>
      <label>Name</label>
      <input id="name" />
      <button type="submit">get a greeting</button>
    </form>
  )
}

// 用 ErrorBoundary 包裹,处理手动抛出的错误
export default withErrorBoundary(Greeting)

总结:
1. 提供 withErrorBoundary 方法来包裹业务组件实现异常捕获
2. 提供 useErrorHandler hook 让开发者自己处理/抛出错误

“闪电五连鞭”总结

再次总结一下“抓错五连鞭”的要点:

  1. 造一个 ErrorBoundary 轮子
  2. componentDidCatch 捕获页面报错,getDerivedStateFromError 更新 ErrorBoundary 的 state,并获取具体 error
  3. 提供多种展示错误内容入口:fallback, FallbackComponent, fallbackRender
  4. 重置钩子:提供 onReset, resetErrorBoundary 的传值和调用,以实现重置
  5. 重置监听数组:监听 resetKeys 的变化来重置。对于拥有复杂元素的 resetKeys 数组提供 onResetKeysChange 让开发者自行判断。在 componentDidUpdate 里监听每次渲染时 resetKeys 变化,并设置 updatedWithError 作为 flag 判断是否由于 error 引发的渲染,对于普通渲染,只要 resetKeys 变化,直接重置
  6. 提供 ErrorBoundary 的2种使用方法:嵌套业务组件,将业务组件传入withErrorBoundary 高阶函数。提供 useErrorBoundary 钩子给开发者自己抛出 ErrorBoundary 不能自动捕获的错误

耗子尾汁,好好反思

打完了这一套“五连鞭”,再次发布上线,一切OK。

然后我找到这位后端,跟他说了线上事故。当时他就流眼泪了,捂着脸,两分多钟以后,就好了。

我说:小伙子,你不讲码德你不懂。他说:对不起,我不懂规矩。后来他说他写了好几年动态语言,啊,看来是有 bear 来。这个年轻人不讲码德。来!骗!来!偷袭我一个24岁小前端,这好吗?这不好,我劝,这位后端,耗子尾汁,好好反思,以后不要搞这样的聪明,小聪明。程序猿要以和为贵,要讲码德,不要搞窝里斗。

谢谢朋友们。

(故事纯属虚构,如有雷同,请自我检讨或者一键三连)

React 项目中 Axios 封装与请求生命周期管理实战 HTTP 客户端是现代前端工程的基础能力,其核心价值在于弥合 React 同步渲染模型与网络异步 I/O 之间的‘时间差鸿沟’。理解请求拦截器、响应拦截器、AbortController 取消机制及与组件生命周期对齐的封装策略,是构建稳定、可维护数据层的关键。Axios 凭借标准化的错误处理、自动序列化、token 注入和 CancelToken(或 AbortController)支持,成为 React 生态中最成熟的 HTTP 管理载体。本文聚焦生产级 Axios 实例封装、Service 层抽象、Cu 阅读详情

相关推荐

React Native状态管理从零实现

深入讲解React Native状态管理的核心机制,手把手带你从零搭建高效状态管理方案,提升React Native应用的响应性与可维护性。

weixin_42502089的博客 333

React 错误边界组件 react-error-boundary 源码解析

{didCatch: false, // 错误是否捕捉error: null, // 捕捉到的错误信息。

weixin_43294560的博客 1769

React Devtools 原理与实战:透视 React 运行时的调试利器

React Devtools 是理解 React 运行时机制的核心工具,其本质是通过浏览器扩展架构,深度集成 React 内部协调器(Reconciler)与 Fiber 树,实现实时组件状态、Hook 调用链与渲染生命周期的可视化。它不依赖 Chrome DevTools Protocol,而是利用 `__REACT_DEVTOOLS_GLOBAL_HOOK__` 私有钩子,在 `commit` 阶段前捕获精准变更数据,支撑 `react diff算法原理` 的实证分析与 `react面试题` 中高频考点

weixin_30271335的博客 359

react之错误边界(Error Boundaries)

错误边界(Error boundaries) 从react v16开始,引入边界错误概念。 核心API getDerivedStateFromError componentDidCatch 1. 目的:某些UI崩溃,不至于整个webapp崩溃 2. 注意⚠️:错误边界无法捕获如下场景的错误 事件处理(了解更多) 异步代码(例如 setTimeout 或 requestAnimationFrame 回调函数) 服务端渲染 它自身抛出来的错误(并非它的子组件) 3.编写错误边界组件 import React

大灰狼的小绵羊哥哥的博客 1428

Hello-Agents:从零手搓AI Native Agent的开源实战教程

Agent(智能体)是AI Native时代的核心系统范式,其本质并非高级Prompt工程,而是具备目标驱动、自主规划、反思迭代与工具调用能力的自治系统。理解Agent需回归基础原理:以ReAct为代表的决策循环范式,强调‘思考-行动-观察’闭环;而MCP协议则定义了多智能体间的标准化通信机制,支撑可扩展、可追溯、跨语言的协作架构。这类技术价值在智能旅行助手、赛博小镇等真实场景中充分显现——涵盖动态任务编排、异常恢复、状态持久化与生产级可观测性。Hello-Agents作为国产高星开源教程,正以‘概念透彻+

weixin_34293911的博客 480

轻量级视图库骨架:业务视图调度与生命周期管理

视图库是现代前端架构中用于组织和调度业务视图的核心机制,其本质并非UI组件集合,而是聚焦于‘何时加载、如何隔离、怎样卸载’的运行时治理能力。它基于模块化注册、动态导入、钩子驱动和错误边界四大原理,提供比传统路由更细粒度的视图生命周期控制,显著提升中后台系统的可维护性与稳定性。技术价值体现在资源按需加载、样式与状态隔离、权限与审计深度集成,以及对微前端、离线部署等复杂场景的天然适配。典型应用场景包括金融合规系统、IoT设备监控大屏、政务审批平台等对可靠性、定制性与安全隔离要求严苛的领域。本文详解一套经3个真实

weixin_33901926的博客 347

React(精读官方文档)-高级指引 - 错误边界

react(精读官方文档) - 高级指引 - 错误边界

xbczrz的博客 618

use-error-boundary:使用钩子在功能组件中使用错误边界

使用错误边界 在功能组件中使用错误边界的React钩子。 通过将子组件包装在提供的ErrorBoundary组件中,可以跟踪子组件的错​​误状态。 :warning: 在阅读有关错误边界及其预期用途的更多信息,这只会在渲染孩子时捕获错误! 安装 npm i use-error-boundary 2.x重大更改 如果要从1.x版本升级,请确保您没有使用errorInfo对象。 挂钩本身和renderError回调不再提供此对象。 对于高级使用,请参阅。 例子和用法 导入钩子: // Named import { useErrorBoundary } from "use-error-boundary

React 中的 ErrorBoundary

React 框架中通过 getDerivedStateFromError 方法进行异常处理,项目开发可以自定义一个类组件并实现该方法进行组件异常处理。

hawk2014bj的博客 1228

国密套件ECC-SM2-SM4-CBC-SM3和ECDHE-SM2-WITH-SM4-SM3

双方交换各自的公钥,最后A计算点(x1,y1) = d1Q2,B计算点(x2,y2) = d2Q1,由于椭圆曲线上是可以满足乘法交换和结合律,所以 d1Q2 = d1d2G = d2d1G = d2Q1 ,因此双方的 x 坐标是一样的,所以它是共享密钥,也就是会话密钥。4、客户端和服务端分别使用工作密钥,计算主密钥,客户端随机数,服务端随机数,字符串常量"key expansion",经PRF计算生成工作密钥。工作密钥包括加密密钥和校验密钥,具体密钥长度由选择的密码算法决定。客户端支持的压缩算法列表。

Java学习笔记 3784

基于SolidWorks宏的草图点坐标自动化提取与Excel集成

本文详细介绍了如何利用SolidWorks宏编程实现草图点坐标的自动化提取并与Excel集成,显著提升机械设计效率。通过VBA代码解析与优化,解决了人工记录坐标耗时易错的问题,并扩展了多草图批量处理、数据可视化等高级功能,适用于数控加工、质量检测等场景。

weixin_29251131的博客 461

React 错误边界指南

虽然在错误到达生产环境之前捕获错误是理想的,但是其中一些错误(例如网络错误)可能会通过测试而影响用户。如果你的 React 组件没有正确地捕捉到第三方库或 React Hooks 抛出的错误,这样的错误要么导致 React 生命周期崩溃,要么到达主执行线程的顶层,导致“白屏”场景:在React 16中,没有捕捉到的错误[…]将导致整个 React 组件树被卸载您的应用程序通过提供适当的可视化反馈和潜在操作(例如:重试机制)来优雅地处理此类错误是至关重要的。

p1967914901的博客 2151

基于h5端的视频录制和回溯功能的实现

整理了一套《前端大厂面试宝典》,包含了HTML、CSS、JavaScript、HTTP、TCP协议、浏览器、VUE、React、数据结构和算法,一共201道面试题,并对每个问题作出了回答和解析。

发果叁 3191

React 错误边界之 react-error-boundary

一、什么是错误边界 错误边界是一种 React 组件,这种组件可以捕获发生在其子组件树任何位置的 JavaScript 错误,并打印这些错误,同时展示降级 UI,而并不会渲染那些发生崩溃的子组件树。错误边界在渲染期间、生命周期方法和整个组件树的构造函数中捕获错误。 注意:错误边界无法捕获以下场景中产生的错误 事件处理 异步代码(例如 setTimeout 或 requestAnimationFrame 回调函数) 服务端渲染 它自身抛出来的错误(并非它的子组件) 如果一个 class 组件中定义了

weixin_42192113的博客 1650

threejs加载3dtiles(倾斜摄影)数据

1、安装3dTilesRenderer 插件 使用npm 安装 npm install 3d-tiles-renderer --save 或者去官网下载都行 GitHub - NASA-AMMOS/3DTilesRendererJS: Renderer for 3D Tiles in Javascript using three.js 2、使用 首先引入,在填入3dtiles数据的地址,可以是文件路径也可以是网站路径 const tilesRenderer = new TilesRend..

weixin_39481659的博客 1万+

OpenClaw简介--windows系统安装OpenClaw

在windows安装OpenClaw实现代替人工操作。步骤流程详细,图文并茂。

直到世界的尽头 5349

学习React错误边界与ErrorBoundary造轮子

1. 学习错误边界与ErrorBoundary造轮子 1-1 基本概念 React官方文档—错误边界 错误边界 - React 重点提要 如果一个 class 组件中定义了 static getDerivedStateFromError() 或 componentDidCatch() 这两个生命周期方法中的任意一个(或两个)时,那么它就变成一个错误边界。当抛出错误后,请使用 static getDerivedStateFromError() 渲染备用 UI ,使用 componentDidCatch

qq_41885921的博客 641

抖音移动端Web用户主页视频列表爬虫实战:逆向加密参数与高频采集方案

App端Hook/抓包:需要安卓逆向、Xposed或Frida,门槛高且容易被风控。官方开放API:限制极多,几乎不开放用户级视频列表。PC端Web:页面加载方式繁杂,且大量依赖懒加载与内部状态。移动端Web(:接口相对稳定,加密逻辑集中,且适合使用Requests/HTTPSession模拟,无需渲染引擎。本文聚焦于移动端Web下的用户主页视频列表爬取,采用Python 3.11 + httpx + PyExecJS + 正则/JSON解析的组合,破解X-Bogus签名和_signature。

2201_76125261的博客 851

封装一个处理 react 异常的最简 ErrorBoundary 组件 &#127877;

前言 ????爱购物 www.cqfenfa.com ???? 从 React 16 开始,引入了 Error Boundaries 概念,它可以捕获它的子组件中产生的错误,记录错误日志,并展示降级内容,具体 官网地址。 ???? 错误边界避免一个组件错误导致整个页面白屏不能使用等情况,使用优雅降级的方式呈现备用的 UI,错误边界可以在渲染期间、生命周期和整个组件树的构造函数中捕获错误。自 React 16 起,任何未被错误边界捕获的错误将会导致整个 React 组件树被卸载 ErrorBoundar

nidongla的博客 322

查找【优快云】- 人工客服

【代码】查找【优快云】- 人工客服。

👨‍💻 前端开发者 | 技术分享者 1403

置顶必读(1) |《YOLOv8实战:从入门到深度优化》专栏导读,带你一文了解本专栏!

🏆 本文收录于 《YOLOv8实战:从入门到深度优化》 专栏,该专栏专注于分享我在YOLOv8目标检测模型中的实战经验,涵盖从入门基础到深度优化的全方位解决方案。无论你是计算机视觉的新手,还是具有多年深度学习经验的专家,本专栏都将为你提供高效、可复现的技术方案,助你掌握YOLOv8的核心技术,提升目标检测性能,突破瓶颈,优化模型,并加速项目开发🚀!

**My Coding Family** 14万+

生产级 React SPA 架构实战:react-starter-kit 的路由守卫、认证状态、tRPC 客户端与主题工程化约定

这是一篇以 `react-starter-kit` 仓库内 [apps/app/AGENTS.md](https://link.gitcode.com/i/16b07d07295392d166493f28395dd10f) 为核心骨架展开的架构指南。该文档不是泛泛的 README,而是一份面向开发者(尤其是 AI 编码 Agent)的**客户端应用工程约定书**,逐条规定了路由、认证、数据获取、组

gitblog_00792的博客 440

IDEA的使用指南

IDEA基于java的使用手册,可以最快速的上手,在使用中不断的丰富自己的使用技巧.

从“文档懂王”到“工程落地”:我用LangChain造了一个会写代码的Agent

这篇文章摘要了作者在使用LangChain、LangGraph和Deep Agents开发编码助手项目时的经验教训与解决方案: 理想与现实的落差:作者发现官方文档的示例与真实项目存在巨大差距,200万字学习笔记在实际开发中失效,遭遇了token消耗失控、路径解析错误和死循环等问题。 框架关系解析:文章拆解了langchain-core(接口标准)、langgraph(运行时引擎)、langchain(应用框架)和deepagents(工具链)之间的层级依赖关系,指出这是从抽象到具体的实现链条。 开发环境搭建

General_zy的博客 610

ssm框架搭建

这个是一个在idea上成功跑起来的ssm框架项目,保存在这里方便以后使用直接下载

pscad IEEE标准系统搭建说明

pscad IEEE标准系统搭建说明,包含典型的IEEE 9节点、14节点、30节点、39节点和118节点系统。内含标准测试系统的原始数据和潮流结果。

八、从零复刻了一个 WorkBuddy:智能体后端核心功能实现全解

本文从零复刻 WorkBuddy 核心能力,通过 9000 行后端与 700 行前端代码,深度解析 Agent 系统的两大核心:ReAct 主循环与上下文预算机制。项目采用分层架构,强调可解释性与稳定性,实现中融入轮次限制、token 预算、重复调用检测三重护栏,并处理模型出错时的“教它改”逻辑。工具系统基于 Pydantic 自动生成 JSON Schema,支持插件式扩展。对比业界框架,突出自研循环在可控性与透明度上的优势,揭示 Agent 开发的本质:不是调库,而是掌控循环。

每天的表现,未来的必然! 343

Camera2Demo

在Camera2 的基础上进行封装,使得Camera2一堆初始化逻辑与Activity分离,降低耦合度,完成预览拍照并保存的操作

从官方 ISO 到精简版 Windows 11:tiny11builder 完整教程

装 Windows 11 时安装器提示硬件不达标,但老电脑明明还能再战几年?tiny11builder 以官方 Windows 11 ISO 为输入,用 PowerShell 加系统自带 DISM 自动产出一份精简 Windows 11 安装 ISO:预装应用被剥离、TPM/CPU 检查被绕过、OOBE 不再强制登录微软账户,旧电脑装系统直接可用。 ## 它适合谁:三条快速自检 - 想让不满足

gitblog_01095的博客 401

全文 - Building AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Less

AI 编程辅助的格局正在经历一场根本性转变:从复杂的 IDE 插件转向通用的、终端原生的智能体(agent)。直接在开发者管理源代码版本控制、执行构建和部署环境的终端中运行,基于 CLI 的智能体为长程开发任务提供了前所未有的自主性。本文介绍OpenDev——一个专为这一新范式打造的开源命令行编程智能体。有效的自主辅助需要严格的安全控制和高效的上下文管理,以防止上下文膨胀和推理退化。

eloudy的专栏 455
上一篇: redux 文档到底说了什么(下)
下一篇: 造一个 idb-keyval 轮子
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

写代码的海怪

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值