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