【问题标题】:React/Redux isomorphic / server-side rendering and media queriesReact/Redux 同构/服务器端渲染和媒体查询
【发布时间】:2016-10-07 08:05:58
【问题描述】:

我开始创建一个基于 Node.js 的同构 React/Redux 应用程序。该项目的一项要求是基于“移动”和“桌面”视图对特定组件进行“自适应”渲染。我已经实现了 Redux action 和 reducer 来在状态中存储有关用户视图的屏幕信息(基于媒体查询 - “small”、“medium”、“large”)。调整大小时,状态/商店会更新。默认状态是“小”。

const defaultState = {
    isMobile: true,
    isTablet: false,
    isDesktop: false,
    sizes: {
        small: true,
        medium: false,
        large: false,
        huge: false,
    },
};

在需要根据屏幕大小在两个不同版本中“自适应”渲染的组件中,我只是做了一个:

如果(小)返回变化1

如果(中等)返回变化2

一切正常。

现在我面临两个问题:

  1. 我的应用程序是同构的,这意味着标记也呈现在服务器端。服务器对用户的浏览器和媒体查询一无所知。所以因为我的默认状态是“small”,所以服务器总是会渲染“variation1”。节点服务器是站点的入口点。看起来渲染需要“延迟”(中间件?),并且服务器需要在 React 应用程序“交付”之前从客户端获取一些关于浏览器宽度的信息。知道如何解决这个问题吗?

  2. 因为渲染是基于状态的,所以即使浏览器大小为“桌面”,加载后“变体 1”总是可以首先看到几毫秒(闪烁)。这是因为 JS 检测需要几毫秒才能将状态更新为当前屏幕宽度。我认为这与上述问题和默认状态一起发挥作用。

我找不到 1 的任何解决方案,但我想肯定有一些同构和响应/自适应的东西。

【问题讨论】:

  • 我很好奇“variation1”是什么。尚不确定它是否与您的问题相关,但变化只是视图的替代呈现,还是还有其他事情发生?
  • “变体 1”和“变体 2”共享相同的数据,但视图看起来不同,行为也不同。就像 1 是一种手风琴式的东西,而 2 只是一个静态布局。与我认为的问题无关。上面描述的问题更普遍。

标签: node.js reactjs serverside-javascript isomorphic-javascript server-side-rendering


【解决方案1】:

在我看来,这是一个非常难以解决的问题,有很多基于“它取决于”的解决方案。 :)

我是 react-sizemereact-component-queries 的作者,这两个库可帮助处理响应式组件,并且遇到了与您在问题中描述的类似问题。根据我的经验,我发现为您的一个问题提出解决方案通常会影响另一个问题。我将通过在下面描述我的经历来详细说明我的意思......

我曾尝试先解决您的“问题 2”:

由于默认状态导致的渲染闪烁是我在最初创建 react-sizeme 库时遇到的。 react-sizeme 是一个高阶组件,它获取组件可用的大小,然后将其传递给您的组件。根据大小,您当然可以选择渲染不同的组件,就像您在示例中所做的那样,因此可能会发生更新闪烁,除非您碰巧遇到了默认状态最佳点。我通过更改react-sizeme 来“克服”这个问题,最初渲染一个空占位符以获得可用的宽度/高度,然后只渲染你的组件,给它“正确的”宽度/高度。这对我来说非常有效。我不再看到 ComponentBob 被渲染,只是被卸载并让 ComponentFoo 立即呈现在它的位置。

然后“问题1”出现了......

react-sizeme 开始流行起来,最终我有了一个希望在服务器端渲染上下文中使用它的库的消费者。但是由于我针对问题 1 进行的修复,服务器端渲染会产生大量空白内容(即我所说的占位符)。在有效负载被传递到浏览器之后,占位符逻辑将启动,最终大小数据将被发送到组件并被渲染。这并不理想,因为您首先会抵消执行 SSR 的任何好处。我与这个用户一起工作,我们决定最好的方法是允许将react-sizeme 配置为在“SSR 模式”下运行。基本上,这需要删除占位符渲染并允许渲染默认组件,这样您就不会在初始服务器响应中获得空白页面,但是您很容易再次遇到组件闪烁问题!

啊啊啊啊啊!看这里的影响! :(

所以基本上解决一个问题会直接影响另一个问题。


我一直在思考这个问题,我相信最好的方法可能是在第一次请求时尝试获取用户浏览器的宽度/高度。这实质上意味着呈现一个简单的实用程序,该实用程序可以提取此信息,然后将其发送回服务器,以呈现用户的初始请求。然后,您可以使用宽度/高度并将其传递给整个组件树(沿途进行数学运算),以继续确定每个组件的可用高度/宽度。这里超级棘手的东西,但可能会奏效。

当然,另一个风险是 google 只是为初始请求索引一个空白页面(即,找出初始宽度/高度的 util 的空白渲染)。您必须尝试使用​​一些巧妙的 HTTP 响应代码,例如重定向等,以确保 google 跟踪到正确呈现的输出。


抱歉,这可能不是您要寻找的答案,但希望我的经验能以某种方式提供帮助或提供某种启发。如果您确实提出了一些有趣的实验,请随时通知我。我很乐意在这方面与您合作。

【讨论】:

  • 感谢@ctrlplusb 的回复。对我来说,这似乎是一个严重的问题。我在服务器上渲染的原因是SEO。因为“移动”和“桌面”上的内容是相同的,所以在我的情况下,爬虫读取的版本并不重要。您描述的“SSR 模式”基本上就是我现在所拥有的——默认状态——伴随着闪烁。在 server-hit 和 react-render 之间使用某种中间件的想法听起来有点棘手,也意味着一个额外的请求(降低性能)。如果我找到解决方法,我会将您发布在这里。
  • 仅供参考,我目前没有太多时间来解决上述问题,所以我在服务器上使用“mobile-detect.js”并将标头信息传递给状态.这样我就不能适应特定的宽度,但我这里的人很乐意这样工作。
  • 我不是 SEO 专家,但对我来说闪烁解决方案不是解决方案,我不认为爬虫(这些天也在阅读 js..),很高兴看到瞬间内容和之后的不同内容...
【解决方案2】:

您可以从服务器上的标头获取用户代理,然后使用返回数据的减速器发送带有用户代理信息的 redux 操作,这样您就可以检测手机/平板电脑/桌面/等上的用户是否并相应地呈现

【讨论】:

  • 我真的觉得这些天仅仅检测设备是不够的。您需要检测分辨率,因为设备本身具有如此不同的分辨率。平板电脑甚至可以与台式机和笔记本电脑竞争。
  • @ctrlplusb 是的,我有点同意你的观点,有许多设备本身具有不同的分辨率,但有时仅使用移动设备、平板电脑、桌面视图可能就足够了,具体取决于用例
  • 我同意@ctrlplusb。我可以嗅探设备,但我认为这不是一种未来证明的方式。那里的设备太多(将来还会更多)。还要求在 767 像素处“中断”。所有
猜你喜欢
  • 2016-03-26
  • 2017-01-05
  • 2015-02-04
  • 2018-03-29
  • 2016-10-12
  • 1970-01-01
  • 2016-04-03
  • 2020-04-22
  • 1970-01-01
相关资源
最近更新 更多