Question

只是想收集一些关于如何在react + redux项目中组织flowtype的意见。这里是一些示例项目结构：

actions
    -> UserAction.js ---> has some flowtype definition related to this action
    -> PostAction.js ---> has some flowtype definition related to this action
    ...
reducers
    -> UserReducer.js ---> has some flowtype definition related to this reducer
    -> PostReducer.js ---> has some flowtype definition related to this reducer
    ...
models
    -> User.js ---> has some flowtype definition related to this model
    -> Post.js ---> has some flowtype definition related to this model
    ...
components
containers

但是，我看到一些开源项目，例如f8正在使用单个文件定义所有类型，例如：

actions
    -> UserAction.js
    -> PostAction.js
    -> types.js --> all types related to actions
    ...
reducers
    -> UserReducer.js
    -> PostReducer.js
    -> types.js --> all types related to reducers
    ...
models
    -> User.js --->
    -> Post.js --->
    -> types.js --> all types related to models
    ...
components
containers

因此，我只想就如何以更具可持续性和可读性的方式组织flowtype提出意见。谢谢

Answer 1

首先，我想澄清术语； flow-typed和flow types是两个不同但相关的概念。

在这种情况下，我们通常是在谈论flow types，而不是flow-typed，后者在概念上与TypeScript的“确定类型”存储库类似。

流类型是导出的要在库中使用的类型，因此有许多不同的方式可以组织它们。这部分是由于在使用类型之前必须先导入类型，因此位于文件顶部。因此，在某些情况下将它们组织在文件外部是有意义的。这与常量的处理方式类似。

第一个示例选择将每种类型都保留在各自的类中，这在大多数情况下都有效，但可以促进大型项目中的循环依赖。此选项可管理的源文件较少，这在较小的项目中很有利。

第二个示例选择导出每个构造的类型；例如：所有动作会一起导出其类型。这减少了循环依赖的机会，并明确了从何处导入类型。对于较大的项目，我建议使用此选项。

而不是：

import type { FooType } from './foo';
import type { BarType } from './bar';

我们可以：

import type { FooType, BarType } from './types';

如何在React + Redux项目中组织流类型

1 个答案: