当前位置：文江博客话题详情

如何用jquery同位素处理大数据集

发布于 2024-12-29 12:56:06 字数 280 浏览 0 评论 0原文

我计划使用很棒的同位素插件来显示联系人列表，然后允许对它们进行过滤。我遇到的问题是，它对于小型数据集效果很好，但我不确定将其扩展到 1000 多个数据的最佳方法。

到目前为止，我的想法是：

加载一个随机子集，然后在单击过滤器时向其中添加节点以填充空白，
当用户滚动分页时加载更多节点，
不显示联系人
，直到选择了足够的过滤器来获取数字低于预定阈值。

我不确定这些是否有效，我希望其他人也遇到过这种情况并能给我一些想法。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

温柔少女心 2025-01-05 12:56:06

您描述的情况非常常见：如何让您的用户访问比他们一次可能看到的详细数据更多的数据。

有多种方法可以回答这个问题，正确的答案完全是主观的：这取决于您的用户试图查看联系人或对联系人执行什么操作。在真正获得满意的解决方案之前，您需要了解用户将使用联系人做什么。

只是猜测（但你会比我更了解！），我希望他们正在做两件事：

查找：寻找特定的联系人，并且他们已经知道他们的姓名/句柄。
探索：寻找特定联系人，但他们不太记得他们的姓名/昵称。或者他们只是浏览。

如果您对所有解决方案进行过滤，那么“查找”目标几乎就可以实现。探索目标是您想要设计的目标：

随机子集：这不是一种很好的浏览方式，因为您基本上只剩下一个子集要浏览，然后您必须显式过滤才能看到任何新内容。当您不确切知道自己在寻找什么时，很难过滤。
无限滚动：现在似乎是一种流行的解决方案。我发现这很麻烦，尤其是当您“无限”地滚动浏览 1000 多个联系人时。对于“探索”目标来说可能不太好。
分页：也很麻烦 - 但如果分页与字母排序相关联，这可能会很好用。
阈值限制：那么……仅仅依靠过滤？在某些极端情况下，这可能会很糟糕，在这些情况下，用户应用了一个过滤器，但他们看不到任何东西，因为阈值仍未达到（也许有很多人使用了最后一个过滤器）名字约翰逊，这就是您搜索的内容）。另外，我认为当您不知道自己在寻找什么时，浏览能力很重要。

我想如果我处于你的立场，我会引入一些联系人的集群。我怀疑超过 1000 个联系人会带来很大的性能问题（少说一百万个！），所以超过 10000 个联系人实际上是一个用户限制：他们无法同时查看 1000 个联系人。

我建议引入一些聚类，可能是按姓氏或姓氏和名字。然后向用户提供一种深入到一个群集但折叠所有其他联系人的方法，这样它们就不会立即可见。 accordian/rollodex 范例中的一些内容。这会给您的用户带来他们正在与“所有联系人”合作的错觉。可能为每个集群引入一个最小数量，这样如果集群足够小，您就不必费心显示它（即，为什么要显示 2、3 或 5 个联系人的集群 - 只需显示联系人）。当应用过滤器时，簇就会消失。

The situation you describe is pretty common: how to give your user access to more data than they can possibly see in detail at once.

There are several ways to answer the question and the correct answer is completely subjective: it depends on what your user is trying to see or do with the contacts. Before you can really get a satisfactory solution, you need to know what the users are going to use the contacts for.

Just guessing (but you would know better than me!), I'd expect there are two things they're doing:

Lookup: Looking for a specific contact and they already know their name/handle.
Explore: Looking for a specific contact but they can't quite remember their name/handle. Or they're just browsing.

If you do filtering for all the solutions, then the Lookup goal is pretty much in the bag. The Explore goal is the one you want to design for:

Random Subset: Its not a great way to browse since you're basically left with a subset to browse and then you must explicitly filter to see anything new. Hard to filter when you don't know exactly what you're looking for.
Infinite Scrolling: seems like a popular solution these days. I find it cumbersome, especially if you are 'infinitely' scrolling thru 1000+ contacts. Probably not great for the Explore goal.
Paging: Also cumbersome - but perhaps if the paging is tied to alphabetical sorting this could work well.
Threshold limiting: so...simply relying on the filtering? This may be bad in some corner cases in which the user applies one filter and they don't see anything b/c the threshold still isn't met (maybe there are a lot of people with the last name Johnson, which is what you searched for). Plus, I think the ability to browse is important when you don't know what you are looking for.

I think if I were in your shoes, I'd introduce some clustering of the contacts. I doubt that the 1000+ contacts is much of a performance problem (in less you're talking a million!), so the 10000+ is really a user constraint: they just can't view 1000 contacts at once.

I'd suggest introducing some clustering, probably by the last name or last name and first name. Then present the user with a way to drill into one cluster but fold up all the other contacts so they're aren't immediately visible. Something in the ream of the accordian/rollodex paradigm. This gives your user the illusion that they are working with 'all the contacts'. Probably introduce a minimal number for each cluster so that if the cluster is sufficiently small you don't bother showing it (ie, why show a cluster for 2 or 3 or 5 contacts - just show the contacts). As filters are applied then, the clusters melt away.

回复收藏 0 原文

过期情话 2025-01-05 12:56:06

采用读取缓存的想法，类似于：

创建一个可以加载一批最多 100 个（或任何可配置数量）元素的方法。它将：
- 在缓存（JS 数组，主键为元素的 ID）中搜索过滤后的项目
- 通过 AJAX 请求过滤的项目
- AJAX 返回的项目将添加到缓存中
- AJAX 返回的项目也会添加到 DOM 底部的“加载”区域（见下文），其中创建的 DIV 的 id 是元素的主键
- 服务器将发送最多 100 个元素。如果没有过滤器，它将发送下一个尚未发送的元素。您需要跟踪加载的元素。如果服务器端（即会话）缓存数据的大小很关键，您可以仅跟踪最高的连续发送 ID（即，如果您发送第一批 ID 1,2,3,6,9,10，则最高 ID 是 3，因此下次您将从 4 发送，...，因此您仅在会话中保留一个值）
将缓存的 DIV 移入/移出同位素容器
创建一种方法，可以使用上述方法 onDomReady 加载并显示第一个按自然顺序排列的 20 个元素（在您的情况下，它将按名称的字母顺序排列）。它可以是 20 个元素或 50 个或任何...
在后台，通过 AJAX 循环加载并批量加载 100 个所有元素。

加载区域可以很简单：

<html>
  <body>
    <!-- the page stuff -->
    <div id="loader" style='display:none'>
      <!-- all elements are loaded here -->
      <div class="item">...</div>
    </div>
  </body>
</html>

这样你就可以在 DOM 中一步步加载所有元素，并且只显示需要的内容。

Taking the idea of Read Through Cache, something like:

create a method that can load a batch of up to 100 (or any configurable number) elements. It would:
- search in the cache (JS array with primary key the ID of the element) for the filtered items
- request by AJAX the filtered items
- items returned by AJAX would be added to the cache
- items returned by AJAX would also be added in a "loading" area at the bottom of the DOM (see below), with the id of the created DIVs the primary key of the element
- the server would send up to 100 elements. If there is no filter, it would send the next elements not yet been sent. You would need to keep track of the loaded elements. If the size of cached data on server side (i.e. session) is critical, you can keep track only of the highest continuous sent ID (i.e. if you send in 1st batch IDs 1,2,3,6,9,10, then the highest ID is 3, so next time you would send from 4, ..., so you keep in session only one value)
create a method that can move the cached DIVs to/from the isotope container
onDomReady load using the method above and display the first 20 elements by natural ordering (in your case it would be alphabetically by name). It can be 20 elements or 50 or any...
in the background, load in loop by AJAX and in batch of 100 all the elements.

Loading area could be simply:

<html>
  <body>
    <!-- the page stuff -->
    <div id="loader" style='display:none'>
      <!-- all elements are loaded here -->
      <div class="item">...</div>
    </div>
  </body>
</html>

This way you can load all elements step by step in the DOM, and you can display only what is needed.

回复收藏 0 原文

风吹过旳痕迹 2025-01-05 12:56:06

在附加和排列大量同位素项目时，我遇到性能不佳的问题，这是因为我是增量添加项目而不是批量添加项目。这应该是一个显而易见的选择，但我忽略了这一点。

请务必使用数组或元素列表，而不是单独加载或删除。

incomingData=['<div>a</div>','<div>b</div>'];
elements=[];

jQuery.each(incomingData,function(ind,val){
    var element = jQuery(val).get(0);
    //$container.isotope('insert', element); //resource heavy
    elements.push(element); 
});

$container.isotope( 'insert', elements ); //less processing

I was experiencing poor performance when appending and arranging a large number of isotope items and it was because I was adding the items incrementally rather than in a batch. It should be an obvious choice, but something that I had overlooked.

Be sure to use an array or list of elements, as opposed to loading or removing individually.

incomingData=['<div>a</div>','<div>b</div>'];
elements=[];

jQuery.each(incomingData,function(ind,val){
    var element = jQuery(val).get(0);
    //$container.isotope('insert', element); //resource heavy
    elements.push(element); 
});

$container.isotope( 'insert', elements ); //less processing

回复收藏 0 原文

~没有更多了~