我遇到的大多数示例似乎总是从URL获取数据。
但是在服务器端,直接从数据库获取数据是否有意义?
因此,在动作创建者中,它看起来像是:
if(typeof document !== 'undefined')
fetch("url/posts").then(response => dispatch(receivedPosts(response))
else
db.select("posts").then(response => dispatch(receivedPosts(response))
此方法相对于其他数据获取方法的优缺点是什么?
答案 0 :(得分:2)
大多数React / Redux应用程序都是在API开发和UI开发之间存在分离的环境中构建的。通常,这些相同的API为移动应用程序以及其他桌面应用程序提供支持,因此您所显示的直接数据库查询将无法用于服务器端呈现。
在您的情况下,您似乎构建了具有单个代码库的完整堆栈应用程序。没有什么不妥,但是你应该考虑一些事情。首先是建立应用程序的可能生命周期。为了更多地了解堆栈而进行的有趣的小方项目,以及将MVP推向市场的初创公司,以及构建一个必须扩展大门的平台的大型企业之间存在巨大差异。这些方案中的每一个都可能引导您对如何设计应用程序层的不同考虑因素。特定于您的工作的一个重要问题是,其他应用程序/平台是否可能需要访问相同的数据,以及不同的团队是否可能最终维护后端和前端。使用node和mongo,可以很容易地创建最初为React应用程序提供服务的API端点,但稍后可以使用本地IOS应用程序。您还可以在维护和增强应用程序时分离关注点。当您将数据访问和UI逻辑完全分开时,调试通常会更容易,因为您可以直接使用邮递员等方式调用API,以确定它们是否提供了正确的数据。
在您的情况下,似乎可能已经从/ post提供API数据,因此您可能会获得我提到的所有这些好处,但仍然可以通过绕过API来跳过网络跳跃,如您的代码段所示。这将在服务器渲染中提供一个更少的故障点并且会更快一些,但是你可能不会获得太多的速度,如果你的API出现网络问题,它们会立即显示在客户端应用程序,所以好处不会走得太远。
我个人只是在React应用程序中进行fetch调用,并以一种将后端和前端移动到两个单独的repos的方式分离出我所有的数据访问/ API逻辑未来。这将使应用程序成为未来潜在增长的好地方。分离问题的好处可以减轻任何轻微的性能影响。如果您遇到缓慢的页面加载,那么可能有很多地方需要调整,通常从db查询本身开始。