构建一个多页闪亮的应用程序-renderUI（）与扩展ui.R的优缺点

Question

我正在构建一个多页的闪亮应用程序-也就是说，该应用程序由几个（独立）主页面组成，这些主页面带有向前和向后（有时）向后的按钮。 据我所知-与the general two possibilities to build a shiny app一致-有两种主要方法

1. 在用户界面（ui.R）中构建页面，然后相应地隐藏和显示每个页面。 @daattali in this demonstration app使用的方法是shinyjs隐藏和显示每个页面。我想如果可以隐藏导航栏或其他导航列表，也可以使用do this by using navbar(), navlist() or tabsetPanel()的方法。这具有updating pages simply via updateTabsetPanel(), updateNavbarPage() or updateNavlistPabel()的优势，使shinyjs不需要。
2. 第二种方法是使用renderUI()在服务器端构建页面并将ui.R限制为存根。这是for example by TomW遵循的方法，将ui限制为renderUI()和doing everything else server side；以及this discussion
中处理的方法

所以我的问题是：

每种方法的优点和缺点分别是什么？在哪些情况下应该或不应该使用每种方法？

我将提供我目前所知道的答案，但会很高兴进行更正和补充。

Answer 1

在用户端构建页面

优势

• Ui仅需构建一次，从而节省了网络流量和服务器负载。
• 更好地控制可用性：UI始终在服务器之前构建，因此all pages are availabe at initialisation time。
• 再次显示页面时，无需重新初始化输入。
• 顺序（并因此最终进行编号，例如CSS类）是显而易见的。

缺点

• 如果要在几页上显示“相同”输入，则两个输入必须为synchronised，而不是simply rebuilding the input using the old value。
• 膨胀的ui.R，可能将ui和服务器逻辑分开；
• 大页面用户端，因为所有页面都是一次构建的，并且只在用户视图中隐藏

在服务器端构建页面

优势

• 更好的控制和动态呈现页面的可能性。
• 可以使用modules for each page。

缺点

• 网络流量和服务器负载；较少地控制可用
• 每个CSS依赖于CSS类的内部计数的样式元素的可能性很难实现。一个示例是color sliderInputs in different colors。

所以我会说： 如果只有几个页面，则您事先知道顺序，或者希望用户在页面之间来回切换，在用户端进行构建。如果页面数量巨大，请仅调用一次页面，或者需要包含动态输入，请在服务器端进行构建。