【发布时间】:2017-10-10 12:47:03
【问题描述】:
我的扩展中有大约 350 行静态 JSON 数据。该数据在内容脚本中使用,并且所有这些都是必需的。它是键值对的列表。每当用户单击页面时,都会检查所有键是否符合条件并执行适当的操作。比如:
{
"ABC": 323.32,
"BDS": 23.12,
"GTO": 96.52
}
最好放在哪里?我提出了三个想法:
- 直接将其包含在内容脚本中。
- 将其加载到事件页面并使用消息传递来检索数据。
- 将其存储在 JSON 文件中,然后以某种方式使用 XHR 检索它。不过,我认为这是不可能的。
我知道localStorage 并且我已经看到了 Chrome 的各种其他类型的存储。但是,它们似乎适用于用户使用扩展程序执行操作时生成的数据。
我的数据是静态的。安装扩展程序后,它不会更改。也就是说,直到扩展收到更新并最终对其进行修改。
现在,数据位于内容脚本中。我认为这不是很好,因为每次打开页面时都会加载它,而它根本不会改变。因此,事件页面似乎更合适。 但是,是否有针对此类数据的设计?
【问题讨论】:
-
它实际上是 JSON 还是 Object 字面量?
-
这个问题太笼统了。你还没有告诉我们你如何使用这些数据。每个内容脚本中实际需要多少数据?它是被加载到数据结构中的东西,然后你只能在每个内容脚本中访问它的一部分吗?我们需要更多信息,以便能够对存储数据的好方法进行任何评估。现在我们所能做的就是提出如何可能做到这一点的想法。
-
如果你总是需要all,每次内容脚本被加载,然后保持它为内容脚本中的Object literal / Object initializer。其他任何事情只会增加复杂性和额外的处理要求。如果您的实际数据源是 JSON,那么您可以在内容脚本中将其作为 JSON 字符串,您可以使用
JSON.parse()对其进行解析,但即使这样也会增加一些开销。跨度> -
不,这也好不到哪里去。该数据在内部存储为 JSON。加载它需要更多处理。您说过您需要全部,每次用户点击页面。这已经足够接近 always 在 every 内容脚本中需要 all 的内容,这样在内容脚本中没有对象的任何可能节省相对而言,用户没有在页面中点击的次数会被所需的额外处理所抵消。
-
如果您想在后台脚本中执行比较(将点击信息发送到后台页面并返回响应),这可能会更节省内存,但是,这真的取决于您需要多久进行一次此类比较,以及您是否愿意让比较在后台脚本中进行。对于 350x 一个 3 个字符串和一个数字,这可能仍然不是更有效。无论哪种方式,您都比那些在每个页面中加载 85kiB jQuery 的扩展开发人员做得更好,只是为了在他们自己的脚本中保存一些字符。
标签: javascript google-chrome google-chrome-extension storage