在搬砖日常中,不知道大家是否经常有这样的困扰,为了使用一个函数将整个库引入,造成依赖过多,甚至滥用,以至于 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 问答或者博客质量参差不齐,需要自己的甄别。
请问大家是如何解决这一问题,或者有哪些平台已经解决了这个问题?
如果没有,我想这是一个不错的点子。
今天 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= )。 |