javascript - 在 React.js 中实现自己的本地化引擎 - 值得吗？

Question

我决定使用 React hooks 编写自己的本地化引擎。我不需要太多的本地化，只想根据所选的区域设置显示消息。我有一些关于性能等方面的问题。

这是我的翻译组件，它只是通过给定的键返回消息:

import React from 'react';
import useLocale from 'store/LocaleContext';

export default ({ k }) => {
  const { messages } = useLocale();

  const msg = messages[k] ? messages[k] : k;

  return <>{msg}</>;
};

如您所见，它使用 react 钩子(Hook)，并且我在上下文提供程序中异步加载了消息。

我的应用程序是中型项目，因此我计划使用 50-100 或更多 <Translate k="messagekey" />其中的组件。

如果这么多组件订阅一个提供了大约 5-6 KB 数据的上下文，是否会影响我的应用程序性能？ (我的意思是消息大小约为 5-10KB)。

用这个引擎代替react-intl好不好？或react-i18n ，如果我忽略其他本地化问题(日期、时间、货币、数字...，仅用于消息)？

<小时/>

编辑:

https://codesandbox.io/s/test-localisations-8kynz这是示例代码和框链接。

您可以看到我创建的整个本地化文件。

我还添加了翻译函数，它不返回组件，而只返回翻译后的消息。这样做是好的做法吗？

Answer 1

使用 Context 时您可能面临的问题是，每次 Provider 更新时，它都会呈现。每次组件渲染其子组件时也会渲染(除非它们被内存)。

根据您描述的情况，我可以想到两种情况。

所有消息是否一次加载？

如果是这种情况，您将进行一次初始渲染，并在获取数据后进行另一次渲染。从此时起，数据将不会改变，并且 Provider 将不会触发新的渲染。

消息是否更新/添加了多次？

在这种情况下，每次 Provider 更新其所有子项时都会进行渲染。如果有很多 child 并且没有被记住，这可能是一个问题。

如果您的案例是第一个案例，我会测试管理上下文内的数据是否存在任何问题。

在第二种情况下，您可能需要考虑其他选项，例如使用 Redux 而不是 Context 或可能使用您建议的库之一。

在这两种情况中的任何一种情况下，如果您在单个对象中管理大量信息，您可能会考虑使用不同的上下文并向应用程序的不同部分提供较小的数据集。