React/Redux 同构/服务器端渲染和媒体查询
React/Redux isomorphic / server-side rendering and media queries
我开始创建一个基于 Node.js 的同构 React/Redux 应用程序。该项目的一个要求是基于“移动”和“桌面”视图的特定组件的“自适应”渲染。我已经实现了 Redux 动作和缩减器来存储关于用户视图的屏幕信息（基于媒体查询 - “小”，“中”，“大”）在状态中。在调整大小时 state/store 得到更新。默认状态是“小”。
const defaultState = {
isMobile: true,
isTablet: false,
isDesktop: false,
sizes: {
small: true,
medium: false,
large: false,
huge: false,
},
};
在需要根据屏幕尺寸在两个不同版本中“自适应”渲染的组件中，我只是做了一个：
if (small) return variation1
if (medium) return variation2
一切正常。
现在我面临两个问题：
我的应用是同构的，这意味着标记也在服务器端呈现。服务器对用户的浏览器和媒体查询一无所知。所以因为我的默认状态是“小”，服务器将始终呈现“variation1”。节点服务器是站点的入口点。看起来渲染需要“延迟”（中间件？）并且服务器需要在 React 应用程序“交付”之前从客户端获取一些关于浏览器宽度的信息。知道如何解决这个问题吗？
因为渲染是基于状态的，加载后总是能先看到“变体1”几毫秒（闪烁），即使浏览器尺寸为“桌面”。这是因为在使用当前屏幕宽度更新状态之前，JS 检测需要几毫秒。我认为这与上述问题和默认状态一起出现。
我找不到 1 的任何解，但我想一定有一些同构的东西 AND responsive/adaptive。
在我看来，这是一个很难解决的问题，有很多基于 "it depends" 的解决方案。 :)
我是 react-sizeme and react-component-queries 的作者，这两个库可以帮助处理响应式组件，并且遇到过与您在问题中描述的类似的问题。根据我的经验，我发现针对一个问题提出解决方案通常会影响另一个问题。我将通过在下面描述我的经历来详细说明我的意思...
我试过先解决你的"problem 2"：
由于默认状态导致的渲染闪烁是我在最初创建 react-sizeme 库时遇到的事情。 react-sizeme 是一个高阶组件，它获取您的组件可用的大小，然后将其传递给您的组件。根据大小，您当然可以选择渲染不同的组件，就像您在示例中所做的那样，因此除非您碰巧达到默认状态最佳点，否则可能会发生更新闪烁。我 "conquered" 通过更改 react-sizeme 来最初渲染一个空占位符以获得可用的 width/height 然后只渲染你的组件，给它 "proper" width/height.这对我非常有效。我不再看到 ComponentBob 被渲染，只是被卸载并让 ComponentFoo 立即渲染到它的位置。
然后"problem 1"出现了...
react-sizeme 开始流行起来，最终我有一个库的消费者希望在服务器端渲染上下文中使用它。但是由于我对问题 1 进行了修复，服务器端呈现会产生大量空白内容（即我正在谈论的占位符）。有效负载被传送到浏览器后，占位符逻辑将启动，最终大小数据将被发送到组件并被渲染。这并不理想，因为您首先基本上抵消了执行 SSR 的任何好处。我和这个用户一起工作，我们决定最好的前进方式是允许 react-sizeme 在 "SSR Mode" 中配置为 运行。基本上这需要放弃占位符呈现并允许呈现默认组件，这样您就不会在初始服务器响应中得到空白页面，但是您很容易再次遭受组件闪烁问题！
啊啊啊啊啊啊！看到这里的影响！ :(
所以基本上解决一个问题会直接影响到另一个问题。
我一直在思考这个问题，我相信最好的方法可能是在第一次请求时尝试让用户浏览器 width/height。这实质上意味着呈现一个简单的实用程序，该实用程序会提取此信息，然后将其发送回服务器以呈现用户的初始请求。然后，您可以使用 width/height 并将其传递到整个组件树（沿途进行数学计算），以继续确定每个组件的可用 height/width 是什么。这里有超级棘手的东西，但可能会奏效。
当然，另一个危险是 google 只是为初始请求索引一个空白页面（即提取初始 width/height 的实用程序的空白呈现）。您将不得不尝试并研究使用一些聪明的 HTTP 响应代码，例如重定向等，以确保 google 跟踪到正确的渲染输出。
抱歉，这可能不是您要找的答案，但希望我的经验能以某种方式提供帮助或提供某种启发。如果您确实提出了一些有趣的实验，请随时通知我。我很乐意与您合作。
您可以从服务器上的 header 获取用户代理，然后使用 return 数据的缩减器发送带有用户代理信息的 redux 操作，这样您就可以检测用户是否在移动 phone/tablet/desktop/etc 并相应地渲染
我开始创建一个基于 Node.js 的同构 React/Redux 应用程序。该项目的一个要求是基于“移动”和“桌面”视图的特定组件的“自适应”渲染。我已经实现了 Redux 动作和缩减器来存储关于用户视图的屏幕信息（基于媒体查询 - “小”，“中”，“大”）在状态中。在调整大小时 state/store 得到更新。默认状态是“小”。
const defaultState = {
isMobile: true,
isTablet: false,
isDesktop: false,
sizes: {
small: true,
medium: false,
large: false,
huge: false,
},
};
在需要根据屏幕尺寸在两个不同版本中“自适应”渲染的组件中，我只是做了一个：
if (small) return variation1
if (medium) return variation2
一切正常。
现在我面临两个问题：
我的应用是同构的，这意味着标记也在服务器端呈现。服务器对用户的浏览器和媒体查询一无所知。所以因为我的默认状态是“小”，服务器将始终呈现“variation1”。节点服务器是站点的入口点。看起来渲染需要“延迟”（中间件？）并且服务器需要在 React 应用程序“交付”之前从客户端获取一些关于浏览器宽度的信息。知道如何解决这个问题吗？
因为渲染是基于状态的，加载后总是能先看到“变体1”几毫秒（闪烁），即使浏览器尺寸为“桌面”。这是因为在使用当前屏幕宽度更新状态之前，JS 检测需要几毫秒。我认为这与上述问题和默认状态一起出现。
我找不到 1 的任何解，但我想一定有一些同构的东西 AND responsive/adaptive。
在我看来，这是一个很难解决的问题，有很多基于 "it depends" 的解决方案。 :)
我是 react-sizeme and react-component-queries 的作者，这两个库可以帮助处理响应式组件，并且遇到过与您在问题中描述的类似的问题。根据我的经验，我发现针对一个问题提出解决方案通常会影响另一个问题。我将通过在下面描述我的经历来详细说明我的意思...
我试过先解决你的"problem 2"：
由于默认状态导致的渲染闪烁是我在最初创建 react-sizeme 库时遇到的事情。 react-sizeme 是一个高阶组件，它获取您的组件可用的大小，然后将其传递给您的组件。根据大小，您当然可以选择渲染不同的组件，就像您在示例中所做的那样，因此除非您碰巧达到默认状态最佳点，否则可能会发生更新闪烁。我 "conquered" 通过更改 react-sizeme 来最初渲染一个空占位符以获得可用的 width/height 然后只渲染你的组件，给它 "proper" width/height.这对我非常有效。我不再看到 ComponentBob 被渲染，只是被卸载并让 ComponentFoo 立即渲染到它的位置。
然后"problem 1"出现了...
react-sizeme 开始流行起来，最终我有一个库的消费者希望在服务器端渲染上下文中使用它。但是由于我对问题 1 进行了修复，服务器端呈现会产生大量空白内容（即我正在谈论的占位符）。有效负载被传送到浏览器后，占位符逻辑将启动，最终大小数据将被发送到组件并被渲染。这并不理想，因为您首先基本上抵消了执行 SSR 的任何好处。我和这个用户一起工作，我们决定最好的前进方式是允许 react-sizeme 在 "SSR Mode" 中配置为 运行。基本上这需要放弃占位符呈现并允许呈现默认组件，这样您就不会在初始服务器响应中得到空白页面，但是您很容易再次遭受组件闪烁问题！
啊啊啊啊啊啊！看到这里的影响！ :(
所以基本上解决一个问题会直接影响到另一个问题。
我一直在思考这个问题，我相信最好的方法可能是在第一次请求时尝试让用户浏览器 width/height。这实质上意味着呈现一个简单的实用程序，该实用程序会提取此信息，然后将其发送回服务器以呈现用户的初始请求。然后，您可以使用 width/height 并将其传递到整个组件树（沿途进行数学计算），以继续确定每个组件的可用 height/width 是什么。这里有超级棘手的东西，但可能会奏效。
当然，另一个危险是 google 只是为初始请求索引一个空白页面（即提取初始 width/height 的实用程序的空白呈现）。您将不得不尝试并研究使用一些聪明的 HTTP 响应代码，例如重定向等，以确保 google 跟踪到正确的渲染输出。
抱歉，这可能不是您要找的答案，但希望我的经验能以某种方式提供帮助或提供某种启发。如果您确实提出了一些有趣的实验，请随时通知我。我很乐意与您合作。
您可以从服务器上的 header 获取用户代理，然后使用 return 数据的缩减器发送带有用户代理信息的 redux 操作，这样您就可以检测用户是否在移动 phone/tablet/desktop/etc 并相应地渲染