React项目中运用React技巧解决实际问题的总结

前言

进入大厂搬砖也有 3 个月了&＃xff0c;我工作中的技术栈主要是 React &＃43; TypeScript&＃xff0c;这篇文章我想总结一下如何在项目中运用 React 的一些技巧解决一些实际问题&＃xff0c;本文中使用的代码都是简化后的&＃xff0c;不代表生产环境。生产环境的代码肯定比文中的例子要复杂很多&＃xff0c;但是简化后的思想应该是相通的。

取消请求

React 中当前正在发出请求的组件从页面上卸载了&＃xff0c;理想情况下这个请求也应该取消掉&＃xff0c;那么如何把请求的取消和页面的卸载关联在一起呢&＃xff1f;

这里要考虑利用 useEffect 传入函数的返回值&＃xff1a;

useEffect(() &＃61;> {
  return () &＃61;> {
    // 页面卸载时执行
  };
}, []);


假设我们的请求是利用 fetch&＃xff0c;那么还有一个需要运用的知识点&＃xff1a;AbortController&＃xff0c;简单看一下它的用法&＃xff1a;

const abortController &＃61; new AbortController();

fetch(url, {
  // 这里传入 signal 进行关联
  signal: abortController.signal,
});

// 这里调用 abort 即可取消请求
abortController.abort();


那么结合 React 封装一个 useFetch 的 hook&＃xff1a;

export function useFetch &＃61; (config, deps) &＃61;> {
  const abortController &＃61; new AbortController()
  const [loading, setLoading] &＃61; useState(false)
  const [result, setResult] &＃61; useState()

  useEffect(() &＃61;> {
    setLoading(true)
    fetch({
      ...config,
      signal: abortController.signal
    })
      .then((res) &＃61;> setResult(res))
      .finally(() &＃61;> setLoading(false))
  }, deps)

  useEffect(() &＃61;> {
    return () &＃61;> abortController.abort()
  }, [])

  return { result, loading }
}


那么比如在路由发生切换&＃xff0c;Tab 发生切换等场景下&＃xff0c;被卸载掉的组件发出的请求也会被中断。

深比较依赖

在使用 useEffect 等需要传入依赖的 hook 时&＃xff0c;最理想的状况是所有依赖都在真正发生变化的时候才去改变自身的引用地址&＃xff0c;但是有些依赖不太听话&＃xff0c;每次渲染都会重新生成一个引用&＃xff0c;但是内部的值却没变&＃xff0c;这可能会让 useEffect 对于依赖的「浅比较」没法正常工作。

比如说&＃xff1a;

const getDep &＃61; () &＃61;> {
  return {
    foo: &＃39;bar&＃39;,
  };
};

useEffect(() &＃61;> {
  // 无限循环了
}, [getDep()]);


这是一个人为的例子&＃xff0c;由于 getDeps 函数返回的对象每次执行都是一个全新的引用&＃xff0c;所以会导致触发渲染->effect->渲染->effect 的无限更新。

有一个比较取巧的解决办法&＃xff0c;把依赖转为字符串&＃xff1a;

const getDep &＃61; () &＃61;> {
  return {
    foo: &＃39;bar&＃39;,
  };
};

const dep &＃61; JSON.stringify(getDeps());

useEffect(() &＃61;> {
  // ok!
}, [dep]);


这样对比的就是字符串 "{ foo: &＃39;bar&＃39; }" 的值&＃xff0c;而不是对象的引用&＃xff0c;那么只有在值真正发生变化时才会触发更新。

当然最好还是用社区提供的方案&＃xff1a;useDeepCompareEffect&＃xff0c;它选用深比较策略&＃xff0c;对于对象依赖来说&＃xff0c;它逐个对比 key 和 value&＃xff0c;在性能上会有所牺牲。

如果你的某个依赖触发了多次无意义的接口请求&＃xff0c;那么宁愿选用 useDeepCompareEffect &＃xff0c;在对象比较上多花费些时间可比重复请求接口要好得多。

useDeepCompareEffect 大致原理&＃xff1a;

import { isEqual } from &＃39;lodash&＃39;;
export function useDeepCompareEffect(fn, deps) {
  const trigger &＃61; useRef(0);
  const prevDeps &＃61; useRef(deps);
  if (!isEqual(prevDeps.current, deps)) {
    trigger.current&＃43;&＃43;;
  }
  prevDeps.current &＃61; deps;
  return useEffect(fn, [trigger.current]);
}


真正传入 useEffect 用以更新的是 trigger 这个数字值。用useRef 保留上一次传入的依赖&＃xff0c;每次都利用 lodash 的 isEqual 对本次依赖和旧依赖进行深比较&＃xff0c;如果发生变化&＃xff0c;则让 trigger 的值增加。

当然我们也可以用 fast-deep-equal 这个库&＃xff0c;根据官方的 benchmark 对比&＃xff0c;它比 lodash 的效率高 7 倍左右。

以 URL 为数据仓库

在公司内部的后台管理项目中&＃xff0c;无论你做的系统面向的人群是运营还是开发&＃xff0c;都会涉及到分享&＃xff0c;那么保留「页面状态」就非常重要了。比如我是运营 A&＃xff0c;在使用一个内部数据平台&＃xff0c;我一定是想向运营 B 分享某 App 的消费数据的第二页&＃xff0c;并且筛选为某个用户的状态的网页&＃xff0c;并且进行讨论。那么状态和 URL 同步就尤为重要了。

在传统的状态管理思路中&＃xff0c;我们需要在代码里用redux、recoil等库去做一系列的数据管理&＃xff0c;但是如果把 URL 后面的那串 query 想象成数据仓库呢&＃xff1f;是不是也可以&＃xff0c;尝试配合react-router封装一下。

export function useQuery() {
  const history &＃61; useHistory();
  const { search, pathname } &＃61; useLocation();
  // 保存query状态
  const queryState &＃61; useRef(qs.parse(search));
  // 设置query
  const setQuery &＃61; handler &＃61;> {
    const nextQuery &＃61; handler(queryState.current);
    queryState.current &＃61; nextQuery;
    // replace会使组件重新渲染
    history.replace({
      pathname: pathname,
      search: qs.stringify(nextQuery),
    });
  };
  return [queryState.current, setQuery];
}


在组件中&＃xff0c;可以这样使用&＃xff1a;

const [query, setQuery] &＃61; useQuery();

// 接口请求依赖 page 和 size
useEffect(() &＃61;> {
  api.getUsers();
}, [query.page, query, size]);

// 分页改变 触发接口重新请求
const onPageChange &＃61; page &＃61;> {
  setQuery(prevQuery &＃61;> ({
    ...prevQuery,
    page,
  }));
};


这样&＃xff0c;所有的页面状态更改都会自动同步到 URL&＃xff0c;非常方便。

利用 AST 做国际化

国际化中最头疼的就是手动去替换代码中的文本&＃xff0c;转为 i18n.t(key) 这种国际化方法调用&＃xff0c;而这一步则可以交给 Babel AST 去完成。扫描出代码中需要替换文本的位置&＃xff0c;修改 AST 把它转为方法调用即可&＃xff0c;比较麻烦的点在于需要考虑各种边界情况&＃xff0c;我写过一个比较简单的例子&＃xff0c;仅供参考&＃xff1a;

https://github.com/sl1673495/babel-ast-practise/blob/master/i18n.js

这样的一段源代码&＃xff1a;

import React from &＃39;react&＃39;;
import { Button, Toast, Popover } from &＃39;components&＃39;;
const Comp &＃61; props &＃61;> {
  const tips &＃61; () &＃61;> {
    Toast.info(&＃39;这是一段提示&＃39;);
    Toast({
      text: &＃39;这是一段提示&＃39;,
    });
  };
  return (
    

这是按钮Button>div>
  );
};
export default Comp;


经过处理后&＃xff0c;转变为这样&＃xff1a;

import React from &＃39;react&＃39;;
import { useI18n } from &＃39;react-intl&＃39;;
import { Button, Toast, Popover } from &＃39;components&＃39;;
const Comp &＃61; props &＃61;> {
  const { t } &＃61; useI18n();
  const tips &＃61; () &＃61;> {
    Toast.info(t(&＃39;tips&＃39;));
    Toast({
      text: t(&＃39;tips&＃39;),
    });
  };
  return (
    

{t(&＃39;btn&＃39;)}Button>div>
  );
};
export default Comp;


放一段脚本的 traverse 部分&＃xff1a;

// 遍历ast
traverse(ast, {
  Program(path) {
    // i18n的import导入 一般第一项一定是import React 所以直接插入在后面就可以
    path.get(&＃39;body.0&＃39;).insertAfter(makeImportDeclaration(I18_HOOK, I18_LIB));
  },
  // 通过找到第一个jsxElement 来向上寻找Component函数并且插入i18n的hook函数
  JSXElement(path) {
    const functionParent &＃61; path.getFunctionParent();
    const functionBody &＃61; functionParent.node.body.body;
    if (!this.hasInsertUseI18n) {
      functionBody.unshift(
        buildDestructFunction({
          VALUE: t.identifier(I18_FUNC),
          SOURCE: t.callExpression(t.identifier(I18_HOOK), []),
        })
      );
      this.hasInsertUseI18n &＃61; true;
    }
  },
  // jsx中的文字 直接替换成{t(key)}的形式
  JSXText(path) {
    const { node } &＃61; path;
    const i18nKey &＃61; findI18nKey(node.value);
    if (i18nKey) {
      node.value &＃61; &＃96;{${I18_FUNC}("${i18nKey}")}&＃96;;
    }
  },
  // Literal找到的可能是函数中调用参数的文字 也可能是jsx属性中的文字
  Literal(path) {
    const { node } &＃61; path;
    const i18nKey &＃61; findI18nKey(node.value);
    if (i18nKey) {
      if (path.parent.type &＃61;&＃61;&＃61; &＃39;JSXAttribute&＃39;) {
        path.replaceWith(
          t.jsxExpressionContainer(makeCallExpression(I18_FUNC, i18nKey))
        );
      } else {
        if (t.isStringLiteral(node)) {
          path.replaceWith(makeCallExpression(I18_FUNC, i18nKey));
        }
      }
    }
  },
});


当然&＃xff0c;实际项目中还需要考虑文案翻译的部分&＃xff0c;如何建立平台&＃xff0c;如何和运营或者翻译专员协作。

以及 AST 处理各种各样的边界情况&＃xff0c;肯定要复杂的多&＃xff0c;以上只是简化版的思路。

总结

进入大厂搬砖也有 3 个月了&＃xff0c;对这里的感受就是人才的密度是真的很高&＃xff0c;可以看到社区的很多大佬在内部前端群里讨论最前沿的问题&＃xff0c;甚至如果你和他在一个楼层&＃xff0c;你还可以现实里跑过去和他面基&＃xff0c;请教问题&＃xff0c;这种感觉真的很棒。有一次我遇到了一个 TS 上的难题&＃xff0c;就直接去对面找某个知乎上比较出名的大佬讨论解决(厚脸皮)。

在之后的工作中&＃xff0c;对于学到的知识点我也会进行进一步的总结&＃xff0c;发一些有价值的文章&＃xff0c;感兴趣的话欢迎关注~

❤️ 感谢大家

1.如果本文对你有帮助&＃xff0c;就点个在看支持下吧&＃xff0c;你的「在看」是我创作的动力。也可以分享给你的小伙伴一起学习哈~

2.关注公众号「前端从进阶到入院」即可加我好友&＃xff0c;我拉你进「前端进阶交流群」&＃xff0c;大家一起共同交流和进步。