Ajax - 加载三级数据的最佳实践/方法
我在确定在我正在构建的应用程序中加载附加数据的方法时遇到了一些困难。该应用程序是一个 CMS，其中单个页面由许多片段组成——一些片段可重用，另一些片段是独占的。
独占片段的示例可能是描述/作者元标记，而可重用片段可能是链接列表。
我当前的方法是加载构成页面大部分的基本数据，例如主体内容、标题、slug、日期（发布/过期/修改）。加载该部分并且 ui 准备就绪后，我加载 2 个附加数据集：元标记的集合；碎片的集合。
我的会议是： 1. 可扩展性 2. 速度 3. 可维护性
我的方法是否合理，或者我应该考虑其他方法？
I'm having some difficulty on settling on an approach for loading additional data in an application that I am building. The app is a CMS in which a single page consists of many fragments--some reusable, others exclusive.
An example of an exclusive fragment might be a description/author meta tag, whereas a reusable fragment might be a list of links.
My current approach is to load the essential data that makes up the bulk of the page, e.g. Main body content, title,slug, dates (publish/expiration/modified). After that portion is loaded and the ui is ready, I load 2 additional datasets: a collection of metatags; a collection of fragments.
My confers are:
1. Scalability
2. Speed
3. Maintainability
Is my approach sound or should I consider another approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我假设您正在使用 AJAX 进行上述延迟加载。
你的方法合理吗？
您问题的答案取决于整个页面（包括片段）的加载速度。当我们想要创建页面已加载的感觉时，使用您的技术，以便用户在心理上不想等待，
当整个页面被认为加载时间太长时，使用该技术。由于“加载时间太长”的衡量标准是主观的，因此我们以 8 秒为例。如果整个页面需要 8 秒才能加载，而部分页面（例如主体等）需要 3 秒，那么明智的做法是先加载这些部分，这样用户心理上就不会觉得等待 8 秒。
至于您的 3 个标准：
可扩展性：延迟加载会增加返回服务器的 http 调用数量，从而在对服务器的总调用数量以及占用服务器数量的可能性方面引入额外的负载。并发连接。因此，延迟加载会给服务器带来额外的开销。但是，如果您的部署环境是正确集群的，那么它不会给您带来任何重大问题。
速度：
这又回到了我之前所说的。如果您的整个页面加载速度非常快，那么对片段进行延迟加载实际上可能会减慢速度（以总秒数计算），因为您正在对服务器进行额外的 HTTP 调用。在这种情况下，你也没有帮助用户的看法。然而，如果加载整个页面的速度很长，那么该技术就有意义，因为它可以提高用户对速度的感知，即使速度加载的总时间可能更长。
可维护性：一个好的实现可以通过一些简单的代码在加载整个页面和片段之间进行选择。这意味着您已经编写了可维护且灵活的代码。
I am assuming that you are using AJAX for lazy loading mentioned above.
Is your approach sound?
The answer to your question depends on how fast the entire page is loading (including the fragments). Your technique is used when we want to create the perception of the page is loaded so the user psychologically don't feel like waiting,
That technique is used when the entire page is deemed too long to load. As the measures of "too long to load" is subjective, let's consider 8 seconds as an example. If the entire page takes 8 seconds to load and partial page such as main body, etc takes 3 seconds, then it is wise to load those portion first so the user psychologically don't feel like waiting for 8 seconds.
As for your 3 criteria:
Scalability : Lazy loading would increase the number of http calls back to the server and thus introducing additional loads in terms of number of total calls to the server as well as the possibility of taking up the number of concurrent connections. As such, lazy loading introduce additional overhead to the servers. However, if your deployment environment is a clustered properly, it should not be causing any major problem for you.
Speed:
This is back to what I said before. If your entire page load very fast then doing the lazy loading of the fragments could actually slow it down (in terms of total seconds) since you are making extra HTTP calls to the server. In this case, you are not helping the perception of the users as well. However, if the speed to load the entire page is long, then the technique make sense as it improve user's perception of speed even total time of speed loading is probably greater.
Maintainability: A good implementation would enable to choose between loading entire page and in fragments by few simple code. That would signify that you have written a maintainable and flexible code.