在iFrame

Question

为我们开发了一段代码，基本（和简化）设计如下：

着陆页有两个部分，第1部分的示例如下

这是相当简单的：点击链接1-1到1-N，它将引导您到页面，例如http://testpage.com/link1-1

现在在第2节中，工作类似于以下所示：

区别在于第2部分中路由到页面的任何链接都包含信息（对于此问题不重要）和iFrame。此iFrame（取决于单击的链接）将加载第1部分中的链接。

我的第一个问题是使用iFrame。这里发生了很多事情：它重新加载整个站点（这意味着从头开始引导所有内容）。有些信息是硬连线的，不会使用if语句重新加载，该语句检查网站现在是否正在iFrame中加载。这对我来说都有点脏。一些命令从iFrame到父窗口进行交叉通信，而有些则没有。跟踪一切都是不可能的。

iFrame没有中间点。主应用程序的路由检查它是否在iFrame中，并从那里随机路由到第1部分的1-N链接之一。这意味着iFrame总是加载大量数据，即使用户不选择它。

我已经向他们提到了以下问题：

• 这是无法管理的
• 内存效率低下
• 影响装货时间

他们说他们已经这样做的原因：

• 沙盒：无需重做CSS
• 代码重用
• 无需跟踪哪些脚本和资产，使用iFrame轻松清理内存

我对前两个语句强烈反对，因为iFrame加载了新版本的CSS，代码可以重复使用，而不使用iFrame。我在3'的时候有点黑暗。

现在回答我的问题。这是唯一的方法吗？该系统在Backbone.js上运行，我几乎完全相信这可以做得更干净，更有效。如果将链接注入div而不是iFrame，清除将加载的所有资源有多难？

Answer 1

嗯，我们拥有mv *框架的主要原因之一是代码可用性。

我们有视图组件，以便我们可以轻松地实例化并将其注入任何您想要的地方。将整个应用程序加载到特定路径的<iframe>以显示特定视图并没有意义，并且忽略了单页应用程序的重点。他们的主要优势之一是浏览器不必一遍又一遍地创建全新的文档并加载（以及处理 - 编译脚本，计算用于绘图的css样式等）相同的资源。

• ＆＃34;沙盒：无需重做CSS＆＃34;

可能有效，具体取决于CSS的编写方式。例如，当在testpage.com:link中自由加载时，视图可能直接位于具有container类的div下，但是当加载到第二部分的小框中时，它可能嵌套在其中（或者最坏的情况，甚至可能不存在）。

所以像.container > .linkView这样的CSS选择器在第二种情况下不起作用，需要将其修改为.container .linkView

可能需要的CSS更改完全取决于DOM结构，复杂性以及当前编写的方式。

• 代码重用

他们的这一点实际上是针对他们的，因为他们创建的视图组件不能在应用程序的任何其他位置重新使用，这就是为什么他们必须在{{1作为一个完全不同的应用程序实例

将整个应用程序加载到<iframe>不是代码重用，而是创建另一个应用程序实例，那里没有任何重用。使用最少的CSS更改（，如果需要）在应用程序的不同位置重用相同的视图是实际的代码重用。

• 无需跟踪哪些脚本和资产，使用iFrame轻松清理内存

跟踪脚本和资产..？为什么我们需要跟踪脚本和资产？这与我们通常从代码手动卸载脚本和资产不同。没有浏览器可以处理这些东西吗？

如果用户碰巧在第1部分中访问了<iframe>，那么当我们在第2部分中访问相同内容时，在单页应用中，我们的优势就是已经加载了所需资产（并已处理< / em>）在浏览器中，如果它不允许浏览器加载所需的额外资产。在我看来，它比浏览器加载和编译link 1-1文档的下划线和jquery中的所有内容要好得多。

关于内存管理 - 在导航到不同路由时删除视图应该释放内存，除非代码有问题。 - 换句话说，代码中存在内存泄漏。在这种情况下采取的正确行动是修复泄漏。

关于你的第一点：

• 它无法管理

这取决于谁在管理代码，如果是那些提出<iframe>的人，也许他们更容易管理：D

我完全同意其他两点。