将复杂内容(想想整个网页树)从一个 Web 应用程序提供给另一个网站的最佳可重用解决方案是什么?

What is the best re-usable solution for serving complex content (think an entire tree of web pages) from one web app to another website?

本文关键字:最佳 网站 另一个 是什么 解决方案 Web 网页 复杂 应用程序 一个      更新时间:2023-09-26

我们的目标是让一个人,类似于嵌入YouTube视频的方式,在我们的SaaS上嵌入一棵网页树到他们自己的网站中

解决方案应该是good lookingcross-browserresponsivesimple给最终用户的(理想情况下,也应该search-bot friendly)。


我们正在考虑两个主要选项,客户只需要copy+paste支持嵌入页面的一部分(例如:中间列)或全宽(例如:标题下的所有内容)的代码片段:

  1. IFRAME:让用户在div 中嵌入一个 iframe,以及一个JS片段,这些片段将在调整窗口大小时调整 iframe 的大小。
  2. JS "APP":让用户将脚本标签粘贴到JS脚本/应用程序中,该脚本/应用程序将与我们的服务器进行跨域通信(通过 CORS 或 JSONP)。

理想情况下,我们希望能够从我们的内容启动全屏模式。

问题/疑虑:

内嵌框架

  • iframe 能否可靠地更新父浏览器窗口的 URL?
  • 我们可以可靠地从 iframe 启动全屏模态吗?
  • 当窗口大小调整或 iframe 内容更改时,我们能否可靠地让 iframe 调整大小?

JS"应用程序"

  • 处理正确封装我们的应用程序以避免命名/库冲突的开销有多大?例如,理想情况下,我们会坚持使用原版JS,但是如果我们想使用像Ember这样的库,并且我们的客户有一个Ember站点。
  • 有什么不明显的跨域陷阱吗?我们将使用 CORS 或 JSONP。

我们希望对以下两个方面提供意见:

  1. 可能执行的操作的技术限制
  2. 我们必须克服每条道路的实际障碍。

附言我们还在考虑一个备份选项,即"假"集成,我们使用子域URL在我们的网站上托管内容(类似于Tumblr让人们在"apple.tumblr.com"之类的东西上托管他们的博客的方式)。如果我们沿着这条路走下去,我们想象让用户为子域主题。我们了解这条道路的利弊。缺点是,这对用户来说工作量更大,他们需要在视觉上保持两个不同的站点同步。

我认为最好的方法是使用与谷歌和其他大公司已经使用了一段时间相同的方法,即嵌入式脚本。它看起来更好,语义无害(就像iframe一样 - 可以说 - 是),超级跨浏览器和简单,事实上,就像跨浏览器和将要推送的代码一样简单(可以建议放在<script async>标签中,这将消除对精心制作的异步脚本的需求, 虽然它不会完全兼容,但它可以正常降级并且在大多数情况下都能很好地工作)。

至于CORS如果采取基本的谨慎措施,则无需担心太多。不过,我想说的是,如果你打算在Ember或Angular中做一些嵌入的东西,那可能是一大堆脚本/字节,甚至会减慢网站/应用程序的速度并影响整个用户体验,对于像这样加载的组件来说可能太多了。因此,只要有可能,在组件中应始终使用vanilla JS,特别是如果由于绑定等特定功能而使用Ember/Angular(特定的vanilla JS代码可以以更少的权重覆盖它)。