代码之家 › 专栏 › 技术社区 › Isaiah Fasoldt

处理共享助手函数的反应方式是什么?

reactjs javascript

Isaiah Fasoldt · 技术社区 · 7 年前

我有点新的反应能力,我正在尝试找出在哪里放置各种需要在我的应用程序中使用的功能是最好的。

例如,我有一个函数,它返回一个 document_type 基于传递给它的文档扩展名的键。

我也有一个 romanize 将一个数字转换成罗马数字的函数。

我还拥有一组围绕进行API调用和解析响应进行分组的函数。

所有这些都需要在应用程序的不同地方访问。据我所知,“反应方式”是通过组件创建实现的可组合性,但对于我来说,很难看到这些作为组件有什么意义,因为我相信组件必须返回JSX。

3 回复 | 直到 7 年前

Tholle 7 年前

您可以创建例如 utils 文件,从那里导出助手,并在需要时导入它们:

// utils.js

export function romanize(str) {
  // ...
}

export function getDocumentType(doc) {
  // ...
}

// App.js

import { romanize } from './utils';

Ben Wencke 7 年前

在某些情况下,您需要像这样的助手函数,并且在Util或Helpers文件夹中设置这些函数是一种很好的处理方法。

但是,为了充分利用React,我建议您考虑一下是否有一种方法可以改为创建共享组件。对于诸如罗马化函数之类的函数,可以生成一个反应组件,该组件格式化传递给它的数字,并在一个范围内显示它。这与React库使用的方法相同,例如 react-intl 图书馆建议使用 <FormattedMessage /> 组件而不是它们的 formatMessage 帮助程序函数。

例如,

const RomanNumeral = ({ number }) => {
    // romanize logic here
    return <span>{result}</span>
}

然后你可以这样使用它:

<RomanNumeral number={5} />

brysgo 7 年前

“反应方式”是以对应用程序最有意义的方式构造这些文件。让我给您举几个例子,说明React应用程序看起来会帮助您解决问题。

react对于视图具有声明性树结构,其他相关概念也有落入这种声明性树结构形式的趋势。

让我们来看两个例子,一个是范例与视图层次结构相关,另一个不是。

如果没有,我们可以考虑您的域模型。您可能需要在类似业务模型的商店中构造本地状态。您的业务模型通常与您的视图层次结构不同,因此我们对此有一个单独的层次结构。

但是业务模型需要连接到视图层的地方呢?因为我们在每个组件的基础上指定数据。尽管它不是视图或样式,也不是组件的行为方式,但它仍然与react组件位于同一文件夹层次结构中,因为它符合同一概念结构。

现在,有一个关于公用事业的问题。有很多方法可以解决这个问题。

如果它们都很小并且是特定于应用程序的,但不是任何部分,那么可以将它们放在utils下的根目录中。
如果有很多实用程序,并且它们适合于与任何现有层次结构分离的结构,那么创建一个新的层次结构。
如果它们独立于您的应用程序,那么上述任何一种方法都可能成为NPM包。
如果它们与应用程序的某些部分相关,您可以将它们放在层次结构中的最高点,这样使用该实用程序的所有内容都位于该实用程序所在的目录下。