我推荐的一种模式是在可能的地方使用选择器来隐藏商店的形状 . 这样，如果您需要更新商店的形状，您应该只能更新您的选择器，而不是更新应用程序的其他部分 .
然而，在该州内使用模型也会出现同样的问题 .
作为众多示例之一，我们假设我正在使用Redux构建文件系统 . 我有一个文件列表，可以是目录或文件 .
我的商店可能有 fileList 属性，其中包含一个文件ID数组以及一个将 fileId 映射到文件对象的 files 对象 .
设's say I have a list of files and I want to, depending on whether it'是一个文件或目录，有一个不同的 Item 组件（即 DirectoryItem 和 FileItem ） .
实现此目的的一种方法是执行以下操作：
{
files.map(file => {
file.type = 'directory' ?
<DirectoryItem key={file.id} ...file /> :
<FileItem key={file.id} ...file />
)}
}
（或者我可以创建一个更高阶的 FileListItem 组件，例如，检查并呈现 DirectoryItem 或 FileItem ）
但是这可能不太理想，因为现在我的组件需要知道文件对象的结构 . 我可能想要添加不同类型的对象（即快捷方式文件或共享文件），并可能决定 type 属性不需要去更新我的所有组件等 .
例如，如果我在Backbone中执行此操作，我可能会选择在我的模型上定义 isDirectory() 函数，但这似乎不是Redux的处理方式 .
我能想到的一个可能的解决方案是创建一个 FileUtils 辅助类，它导出 isDirectory 方法并将文件对象作为参数 .
另一种选择是创建一个 isDirectory 选择器，它将文件id作为prop，执行如下操作：
(files, props) => state.files[props.fileId].type == 'directory'
如果我要创建选择器，我想我需要创建一个更高阶的组件来调用选择器 .
只是想知道Redux中是否建议采用这两种方法？我错过了另一种可以帮助解决这个问题的方法吗？
1 回答
功能性的处理方式只是规定撕掉对象的方法并将其称为函数 .
调用它的推荐方法是，只需传递一个常规参数，而不是
this. 这不是必需的 . 你可以使用call或apply. 这在js中可能看起来很奇怪，但是这可能会很快改变一个新的::运算符 .现在，您可以为此函数提供任何您喜欢的功能，以帮助其获取数据 .
在你的例子中
你传递状态（命名错误）和道具，然后使用此信息来得出答案 . 但您可以选择将目录条目对象传递给它 . 无需从州获取它 .
请注意，这使它非常接近方法 .
现在，因为它没有获得状态，所以它不是从状态中选择任何东西，因此不是选择器 .
然而，它在本质上是充足的功能 . 真的没有必要或使用让生活变得更复杂 . 添加更高阶的组件或者试图将我们的问题变成更加Redux-y的做事方式是不必要的复杂问题 .
建议选择器用于选择状态，因此状态使用不依赖于状态形状 . 它是一个抽象层，将你的
mapStateToProps与你的reducer分开 .选择器现在被认为是Redux Way的一部分，但并非总是如此 . 因此，根据您的判断，随时了解事情的原因，您可以选择不使用它 .
并且，您可以自行决定使用自己的版本替换当前趋势 . 强烈建议在考虑替代方案后这样做 .
通常最好的解决方案就是你自己提出的解决方案 . 作为最了解您的问题域的人，您有资格制定匹配的解决方案 .
那些已经发展出伟大创意的人，如果有更好的东西出现，可能会从他们的观点出发 .
没有（也可能不应该）是一个神圣的范例 . 一切都有资格重新考虑 . Occam的剃刀决定最简单的答案很可能是正确的答案 .
而Redux非常关注简单性 . 所以要做的事情，Redux Way主要是以直截了当的方式做事 .