有不同的“无限滚动”方法或按您的说法提供。用户的需求和可接受的响应有效负载的大小将决定您选择哪一种。
在这里，您似乎在满足性能的同时牺牲了可用性。
1. 追加资产 http://binarymuse.github.io/ngInfiniteScroll/
此方法是传统的追加到底部方法，如果用户到达当前滚动高度的底部，将进行另一个 API 调用以“堆叠更多”内容。这样做的好处是，它是处理跨设备警告的最有效解决方案。
正如您所提到的，该解决方案的缺点是当用户不小心滚动内容时，大量有效负载会淹没内存。没有油门。
<div infinite-scroll='getMore()' infinite-scroll-distance='0'>
<ul>
<li ng-repeate="item in items">
{{item}}
</li>
</ul>
</div>
var page = 1;
$scope.getMore() = function(){
$scope.items.push(API.returnData(i));
page++;
}
2.添加带有节流阀的资源
在这里，我们建议用户可以继续在无限追加的提要中显示更多结果，但必须限制它们或“手动”调用更多数据。相对于用户将滚动浏览的返回内容的大小，这变得很麻烦。
如果每个有效负载返回大量内容，则用户将不得不更少地单击“获取更多”按钮。当然，这是以返回更大的有效负载为代价的。
<div>
<ul>
<li ng-repeate="item in items">
{{item}}
</li>
</ul>
</div>
<div ng-click='getMore()'>
Get More!
</div>
var page = 1;
$scope.getMore() = function(){
$scope.items.push(API.returnData(i));
page++;
}
3. 虚拟卷轴 http://blog.stackfull.com/2013/02/angularjs-virtual-scrolling-part-1/
这是无限滚动的最后也是最有趣的方式。这个想法是，您仅将一系列结果的渲染版本存储在浏览器内存中。也就是说，复杂的 DOM 操作仅作用于配置中指定的当前范围。然而，这有其自身的缺陷。
最大的就是跨设备兼容性。
如果您的手持设备有一个虚拟滚动窗口，其宽度达到设备的宽度，那么最好小于页面的总高度，因为您将永远无法使用其自己的滚动条滚动经过此“提要”。您将被“卡在”中间页面，因为您的滚动将始终作用于虚拟滚动提要而不是包含提要的实际页面。
接下来是可靠性。如果用户手动将滚动条从低索引拖动到极高索引，您将强制浏览器非常非常快地运行这些指令，这在测试中导致我的浏览器崩溃。这可以通过隐藏滚动条来解决，但是当然用户可以通过非常非常快地滚动来调用相同的场景。
这是演示 http://demo.stackfull.com/virtual-scroll/#/comparison
来源 https://github.com/stackfull/angular-virtual-scroll
"Initial page must static for SEO reasons. It's important that the framework be able to start with existing content, preferable with little fight."
那么您的意思是您希望页面在提供内容之前在服务器端进行预渲染？这种方法在早期的几千年中效果很好，但大多数人都在放弃这种方法并转向单页应用程序风格。有充分的理由：
您发送给用户的初始种子充当获取 API 数据的引导程序，因此您的服务器所做的工作要少得多。
延迟加载资源和异步 Web 服务调用使得感知加载时间比传统的“首先渲染服务器上的所有内容，然后将其返回给用户的方法”快得多。
您可以通过使用页面预渲染/缓存引擎来保留您的搜索引擎优化，该引擎位于您的网络服务器前面，仅使用您的“完全渲染版本”响应网络爬虫。这个概念很好解释here http://theothersideofcode.com/what-is-stopping-google-from-indexing-single-page-javascript-applications.
we would prefer to have the data needed for the lightbox loaded already in feed so that the transition can be faster. Some of the data is already there (title, description, photos, num likes/ num bookmarks,num comments) but there is additional data that would be loaded for the detail view - comments, similar posts, who likes this, etc.
如果您的 feed 的初始有效负载不包含每个“feed id”的子数据点，并且需要使用额外的 API 请求将它们加载到您的灯箱中 --- 您的做法是正确的。这完全是一个合法的用例。您可能会认为单个 API 调用需要 50-100 毫秒，这对于您的最终用户来说是无法察觉的延迟。如果您绝对需要通过 Feed 发送额外的有效负载，那么您并没有赢得太多。
Changes to the post that happen in the feed or detail lightbox should be reflected in the other with little work (eg, if I like it from the feed, I should see that like and new like count number if I go to the lightbox - or the opposite.)
你在这里混合了技术 --- Like 按钮是对 facebook 的 API 调用。这些更改是否会传播到同一页面上 facebook 类似按钮的其他实例取决于 facebook 如何处理它，我相信快速谷歌会帮助你。
然而，特定于您网站的数据——有几个不同的用例：
假设我更改了灯箱中的标题，并且还希望将更改传播到当前显示的提要。如果您的“保存编辑操作”POST 到服务器，则成功回调可能会触发使用 Websocket 更新新值。此更改不仅会传播到您的屏幕，还会传播到其他所有人的屏幕。
您还可以讨论双向数据绑定（AngularJS 在这方面很擅长）。通过双向数据绑定，您的“模型”或从 Web 服务返回的数据可以绑定到视图中的多个位置。这样，当您编辑共享同一模型的页面的一部分时，另一部分将随之实时更新。这发生在任何 HTTP 请求之前，因此是完全不同的用例。
We would like to migrate our mobile site (currently in Sencha Touch) to also use the same code base for the parts that are common so we can have closer feature parity between mobile and main site.
你真的应该看看现代的响应式 CSS 框架，比如引导程序 http://twitter.github.io/bootstrap/ and 基础 http://foundation.zurb.com/。使用响应式网页设计的要点是，您只需构建一次网站即可适应所有不同的屏幕尺寸。
如果你谈论的是功能模块化，AngularJS 更胜一筹。这个想法是，您可以将网站组件导出到可用于另一个项目的模块中。这也可以包括视图。如果您使用响应式框架构建视图，您猜怎么着 — 您现在可以在任何地方使用它。
1) Will it be possible/problematic to have initial page loads be static while rending via the templates additional pages.
如上所述，最好放弃这些方法。如果您绝对需要它，模板引擎并不关心您的有效负载是在服务器端还是客户端呈现。部分页面的链接也同样容易访问。
2) is it problematic to have multiple data-sources for different parts of page - eg the main post part comes from embedded json data and from "see more"s in the feed while the additional detail would come from a different ajax call.
同样，这正是该行业正在迈向的方向。您将使用获取所有外部 API 数据的初始静态引导程序来节省“感知”和“实际”加载时间 --- 这也将使您的开发周期更快，因为您正在分离完全独立的部分的关注点。你的 API 不应该关心你的视图，你的视图也不应该关心你的 API。这个想法是，当你将 API 和前端代码分解成更小的部分时，它们都可以变得模块化/可重用。
3) While the two-way binding is cool - I'm concerned it might be a negative in our case because of the number of items being rendered. The number of elements that we need two-way binding is relatively small.
我还将把这个问题与您在下面留下的评论结合起来：
Thanks for the answer! Can you clarify - it seems that 1) and 2) just deal with how you would implement infinite scrolling, not the performance issues that might come from such an implementation. It seems that 3 addresses the problem in a way similar to recent versions of Sencha Touch, which could be a good solution
您将遇到的性能问题完全是主观的。我试图在讨论中概述诸如限制之类的性能注意事项，因为限制可以极大地减少服务器所承受的压力以及用户浏览器对附加到 DOM 中的每个新结果集所做的工作。
一段时间后，无限滚动会耗尽用户的浏览器内存。我可以告诉你的是，这是不可避免的，但只有通过测试你才能知道多少。根据我的经验，我可以告诉您用户浏览器可以处理大量滥用，但同样，每个结果集的有效负载有多大以及您在所有结果上运行的指令完全是主观的。有些解决方案仅在我描述的选项三中的范围数据集上呈现，但也有其局限性。
返回的 API 数据大小不应超过 1-2kbs，并且返回查询只需要大约 50-200 毫秒。如果您没有达到这些速度，也许是时候重新评估您的查询或通过使用子 ID 查询其他端点以了解具体信息来减少返回的结果集的大小。
