我正在尝试构建一个UI,左边的条形有过滤器,右边有实际的过滤数据。对于将数据加载到UI的动态部分(右侧),哪种方法在代码质量和应用程序性能方面被认为更好?
发布于 2018-12-03 00:10:36
对此没有一个直接的正确答案;你可以使用这两种方式,但这里有几件事要考虑,最后,我通常更喜欢使用子路线,因为以下原因:
model
、beforeModel
等)将在显示数据之前等待承诺得到解决。如果您只是提供一个加载模板(参见详细信息指南),默认情况下将显示该模板。如果您使用组件,您可能需要处理显示覆盖/旋转器以提供更好的UX。filter
值的应用程序。这意味着您需要在init
、willRender
、didReceiveAttrs
组件钩子方法的一个或多个方法中对服务器进行一些远程调用。我个人不喜欢在这些方法中进行远程调用;因为我觉得这应该在路由内进行,数据应该传递给组件;但这是我个人的编码品味,您应该以不同的方式处理这个问题,这是非常好的。发布于 2018-12-03 03:19:21
数据向下,动作向上保持组件的灵活性。
在您的具体示例中,我将提出第三个选项:发出操作的独立组件,它们的数据由路由的控制器加载,并且永远不会直接按照DDAU操作它们传递的参数。
我将有一个组件search-filter searchParams=searchParams onFilterChange=(action 'filterChanged')
用于搜索过滤器,另一个组件是search-results data=searchResults
来显示数据。
让我们先看看搜索过滤器。使用操作提供了最大的灵活性,因为搜索过滤器只是在更改时发出某种类型的搜索对象。您的控制器操作如下所示:
actions: {
filterChanged(searchParams){
this.set('searchParams', searchParams);
//make the search and then update `searchResults`
}
}
这意味着您的search-filter
组件将所有搜索过滤器字段聚合到一个单独的搜索对象中,该对象用作onFilterChange
的唯一参数。
您现在可能会想,“那么,为什么不直接从组件内部进行搜索呢?”您可以这样做,但是这样做意味着在加载时,首先将params传递给组件,然后在didInsertElement
上进行默认搜索,该搜索会发出一个操作结果,该操作将更新searchResults
值。我发现这个控制流并不是最明显的。此外,您可能需要发出一个onSearchError
回调,如果搜索操作/搜索筛选器参数可以一起应用,则可能需要发出其他操作/助手选项,这些操作将有条件地依赖于应用程序中的页面。
每当搜索筛选器字段更改时,接收搜索对象并发出动作的组件很容易推理。由于searchParams
是单向绑定的,在其模板中使用此组件的任何route
都可以控制字段字段是否更新(在无效情况下可选地阻止searchParams
的更新),或者搜索是否触发基于routes
之间可能不同的验证规则。此外,在单元测试期间,不存在对依赖项的模拟。
在使用子线路之前要三思
对于您问题的subroutes
部分,我发现深度嵌套的路由几乎总是反模式。我的意思是,在app->first-child->second child
之外,第一个孩子是一种类似于菜单的结构,它通过简单的{{link-to}}
帮助程序在second child
级别控制不同显示之间的变化。如果我必须在父母和孩子之间共享状态,我就创建一个first-child-routes-shared-state
服务,而不是执行modelFor
或controllerFor
歌曲和舞蹈。
您还必须考虑在辩论如何使用子route
与{{if}}
{{else}}
节时,back按钮行为是否应该返回到前一步,还是在进入整个部分之前返回到路由。在一个从创建->审查->完成的线上传输向导中,我真的应该在已经付款之后按下从完成到检查的后退按钮吗?
在searchFilter
+ displayData
的情况下,他们对我来说总是在同一条路上。如果在URL刷新时搜索值需要持久化,则选择查询参数。
最后,请注意,仅仅因为/users/:id/profile
意味着嵌套,您也可以使用this.route('user-profile', { 'path' : 'users/:id/profile' })
并完全避免嵌套。
https://stackoverflow.com/questions/53572759
复制相似问题