我希望我的基于React的SPA能够在服务器端呈现(现在不是这些日子)。因此,我想将React与react-router,redux和一些构建层(如isomorphic starterkit)结合使用。如何在逻辑上组合react-router和redux以进行客户端和服务器端渲染
有hapi universal redux加入到一起,但我正在努力如何组织我的流量。我的数据来自REST API的多个端点。不同的组件有不同的数据需求,应该及时在客户端上加载数据。而是在服务器上,必须获取特定路由(组件集合)的所有数据,并将必要组件呈现为字符串。
在我的第一个方法中,我使用了redux的中间件来创建异步操作,它加载数据,返回一个承诺,并在承诺解决时触发一个SOME_DATA_ARRIVED
操作。 Reducers然后更新我的商店,组件重新渲染,都很好。原则上,这是有效的。但后来我意识到,在路由开始的时候,流量变得尴尬。
某些列出大量数据记录的组件具有多个链接来过滤记录。每个过滤的数据集应该可以通过它自己的URL(如/filter-by/:filter
)获得。所以我使用不同的<Link to={...}>
组件在点击时更改URL并触发路由器。路由器应根据当前URL所代表的状态更新商店,从而导致相关组件的重新呈现。
这并不容易实现。我首先试着componentWillUpdate
来触发一个动作,它异步加载我的数据,填充存储并为我的组件导致另一个重新呈现周期。但是这不适用于服务器,因为只支持3种生命周期方法。
所以我正在寻找正确的方式来组织这一点。从用户角度更改应用程序状态的用户与应用程序的交互应更新URL。海事组织这应该使路由器以某种方式加载必要的数据,更新商店,并启动对帐过程。
所以interaction -> URL change -> data fetching -> store update -> re-render
。
这种方法也应该在服务器上工作,因为根据请求的URL,应该能够确定要加载的数据,生成initial state
并将该状态传递到store
generation的redux。但我没有找到正确的方法。所以对我来说,出现以下问题:
- 我的方法错了吗,因为有些东西我不明白/知道吗?
- 将REST API的数据加载到redux的
store
中是否正确? - 是不是有一个尴尬的组件,其中
state
在reduxstore
和其他人管理他们state
自己? - 想法有
interaction -> URL change -> data fetching -> store update -> re-render
简直是错的吗?
我对每一种建议都是开放的。