我继承了一些使用props钻取的代码，将大量常量（翻译）传递给各个子组件。这些翻译将符号映射到本地语言文本，还有一个函数来执行名为translate的映射。即{translate（SYM_NO）}将返回＆＃34; NON＆＃34;如果当地语言是法语。
我认为Props钻孔有点乱，决定在React 16.3.1中使用新的Context。这对JSX来说很好用，但是当我需要转换成JS例如MS Fabric UI DetailsList回调时这有点棘手，因此回调可以转换各种列数据（由API调用返回）。下面是一个将参数（从Context）添加到回调的技术，然后可以在回调实现中使用：
onRenderItemColumn={(item, index, column) => this._renderItemColumn(item, index, column, translate)}
在让这个工作之后，我发现它实际上是不必要的，因为我可以在任何（大多数）组件中导入翻译，并且可以在我的JSX或JS中的任何地方轻松使用翻译： -
import translate from "../../../config/translate";
所以我现在想知道几乎所有组件中导入translate的性能/内存含义。每次进口是否都会受到处罚，或者只是第一次重要进口而其余进口没有影响？
我应该继续使用许多导入还是恢复（棘手）Context或者其他一些方法。 （我认为道具钻孔不是一种选择）
彼得（React newb）答案 0 :(得分：1)
假设您使用基于Webpack的标准React堆栈，性能方面的开销应该是最小的，因为它们都是引用相同的模块，只评估一次。维护明智，根据我的经验，它很快就会成为负担。特别是当您考虑到导入是相对于您导入的文件时。“此文件是四级深度还是六级”。使移动文件变得痛苦。并为某些模块添加别名，以便您可以使用绝对路径导入它们，这会增加新开发人员的复杂性。
上下文不是我认为最好的方法，因为您需要将消费者添加到需要翻译的所有部分。
我建议您研究一下，如果高阶订单组件为您点击。这样做的好处是不会使组件呈现逻辑与消费者混淆，并且可以作为额外功能添加到需要以非常透明的方式进行翻译的所有组件。在伪代码中：export default withTranslations(Component);
你仍然需要导入withTranslation，你将导入你的配置/翻译模块，但实现它会对我更有意义。
在React中也有一些用于i18n的NPM模块，我使用的所有模块也使用了更高阶的组件方法，这让我相信它也可以为你工作。