Javascript 如何在后退/前进或刷新后保留数据表中的筛选器

我们使用DataTables作为我们的表，但我们在保留以前应用于表的过滤器的历史记录方面遇到了问题/分歧，因此用户可以通过这些过滤器来回刷新

现在，提出的一个解决方案是，我将过滤器字符串保留在URL中，并将其作为GET请求传递，这将很好地处理来回和刷新。但是由于我有非常定制的过滤选项（嵌套的过滤器组），过滤器字符串变得非常长，实际上太长了，由于长度限制，无法在GET请求中传递它

因此，GET是不可能的，显而易见的解决方案是POST请求，这是我们无法达成一致的

第一个解决方案是使用POST请求，每次尝试来回或刷新时都会弹出“恼人的”弹出窗口。我们还打破了我们在整个站点中使用的POST/Redirect/GET模式，因为没有GET

优点：

• 简单解
• 没有对服务器的第二次请求
• 没有额外的数据库请求
• 没有额外的数据库数据
• 仅当您选择将筛选器保存到数据库时，才可以随时重新应用它

缺点：

• 打破发布/重定向/获取模式
• 必须使用pushState（history.js）推送POST数据
• 如何让刷新工作

第二种解决方案是使用POST请求，服务器端将数据保存在DB中，获取用于请求保存数据的ID，然后返回该ID，然后客户端使用该ID执行GET请求，服务器端将该ID与数据匹配，返回正确的过滤器，从而保留POST/Redirect/GET模式。此解决方案发出两个请求，并将用户使用的每个筛选器保存到数据库中。每个用户在数据库中只保存有限数量的“历史”过滤器，旧的过滤器会随着新过滤器的应用而被删除。基本上，服务器端会通过将长数据保存到数据库来缩短URL，就像URL缩短站点一样

优点：

• 保持POST/Redirect/GET模式
• 由于post数据被再次发送，在来回和刷新页面时没有弹出消息

缺点：

• 复杂解
• 对服务器的附加请求
• 对数据库的附加请求
• 数据库中有大量数据，除非用户来回或刷新页面，否则这些数据将不会被使用

---

第三种解决方案是非常受欢迎的，或者从上面选择一种，最好解释一下原因。

这是我刚刚想到的一个转瞬即逝的想法……您可以使用bStateSave保存长度、筛选、分页和排序的状态

---

我的想法是，从理论上讲，您可以将datatables.js生成的cookie保存到数据库表中，就像您在第二个解决方案中提到的那样，但是每次您想要覆盖当前过滤器时，请求都必须发生，用以前的“历史”cookie替换当前cookie

我们也考虑了cookie路由，但是昨天我们决定返回GET请求，并对其进行优化以使其工作。我们成功地缩小了发送到服务器的所有内容，因此现在即使制作一个长过滤器也不会达到GET length限制。我们使用了一个JSON minifyer，然后自己做了一些预处理，使它变得更小。