这是一个创建于 2540 天前的主题，其中的信息可能已经有所发展或是发生改变。
在搬砖日常中，不知道大家是否经常有这样的困扰，为了使用一个函数将整个库引入，造成依赖过多，甚至滥用，以至于 npm 生态形成了一种依赖滥用的习惯，left-pad 事件是这种现象的一个侧面。
有些函数，其功能非常 pure，例如浏览器 URL 的处理函数，通常的做法是在 Stack Overflow 找一些现成的实现。举一个例子，以下代码可以得到一个 URL Query 字典：
function getQueries() {
let options = {};
if (window.location.search) {
options = decodeURIComponent(window.location.search.slice(1))
.split('&')
.reduce(function _reduce(a, b) {
b = b.split('=');
a[b[0]] = b[1];
return a;
}, {});
}
return options;
}
按照常识，这是有最佳答案，即一个已解决的问题（当然，目前主流浏览器中可以使用 URLSearchParams，但仍需要 polyfill https://caniuse.com/#feat=urlsearchparams ），而不是一个应在 Stack Overflow 搜索的问题。
出于对代码库透明性的追求，我倾向避免使用细碎的依赖，建立自己的 Util 库。但碰到类似以上举例的新问题时，往往仍需要求助于搜索引擎，而搜索引擎指向的 SO 问答或者博客质量参差不齐，需要自己的甄别。
请问大家是如何解决这一问题，或者有哪些平台已经解决了这个问题？
如果没有，我想这是一个不错的点子。
第 1 条附言 · 2017-12-13 15:25:11 +08:00
今天 Github 有一个短代码的 热门项目，很好地体现了这一需求
 |
1
LxExExl 2017-12-07 01:59:04 +08:00 via iPhone
能直接拿来用的存在笔记里
否则搜一下又不会死 反正经常搜 搜起来也挺快的 |
 |
2
doublleft 2017-12-07 10:09:11 +08:00
很多人想做过这个，我也做过，但是内容太难搞
|
 |
4
josherich OP @doublleft 生产内容是困难的，这是一个 UGC 的常见问题（最近看到 Stack Overflow Documentation 失败的案例 https://meta.stackoverflow.com/questions/354217/sunsetting-documentation，即使有如此优秀的社区加持，依然无法克服这个难题）
因此显然需要一个发现或自动生成的机制，用 github、gist 或 npm 的数据来做启动，Sourcegraph 等工具可以实现代码库的搜索（例如在 React 中搜索 Object.assign https://sourcegraph.com/search?q=repo:github.com/facebook/react+Object.assign&sq= ）。 |
Select Language