javascript - 在 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。我对第三个有点一无所知。

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

Answer 1

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

我们有 View 组件，以便我们可以轻松实例化并将其注入(inject)到您想要的任何地方。将整个应用程序加载到<iframe>中在特定路线上显示特定 View 没有意义，并且失去了单页应用程序的意义。它们的主要优点之一是浏览器不必创建全新的文档并一遍又一遍地加载(和处理 - 编译脚本、计算绘图的 CSS 样式等)相同的资源。

• “沙盒:无需重做 CSS”

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

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

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

• 代码重用

他们的这一点实际上是反对他们的，因为他们创建的 View 组件不能在应用程序的其他任何地方重新使用，这就是为什么他们必须将其加载到 <iframe> 中。作为一个完全不同的应用程序实例

在 <iframe> 中加载整个应用程序不是代码重用，而是创建应用程序的另一个实例，那里没有任何东西被重用。在应用程序的不同位置重用相同的 View ，只需最少的 CSS 更改(如果需要)就是实际的代码重用。

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

跟踪脚本和 Assets ..？为什么我们需要跟踪脚本和 Assets ？这不像我们一般从代码中手动卸载脚本和资源。浏览器不处理这些东西吗？

如果用户碰巧访问link 1-1在第 1 部分中，当我们访问第 2 部分中的相同内容时，在单页应用程序中，我们的优势是所需的资源已在浏览器中加载(并处理)，并且如果不让浏览器加载所需的额外资源。它比浏览器加载和编译来自下划线和 jquery 的所有内容要好得多 <iframe>我认为文档。

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

<小时/>

关于你的第一点:

• 难以管理

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

我完全同意另外两点。