在构建自己的 JavaScript 库或 jQuery 插件时,我是否必须避免侵入性?

发布于 2024-12-12 06:47:07 字数 441 浏览 1 评论 0原文

最近,我一直在构建一些 JavaScript 库以及一些 jQuery 插件,并且我有一个“utils.js”文件,其中放置了 ArrayString、Number 等,我将其包含在库或插件的最终缩小版本中。

像这样的:

String.prototype.custom_method = function() {
  // Do custom stuff
};

Array.prototype.custom_method = function() {
  // Do custom stuff
};

所以,这些是我的问题:

  • 我必须避免这种情况吗?这是一个不好的做法吗?
  • 如果我将这些方法放在每个库/插件范围中会更好吗?

Lately, I've been building some JavaScript libraries as well as some jQuery plugins, and I have a 'utils.js' file where I put all my custom functions for Array, String, Number, etc. and which I include in the final minified version of the library or plugin.

Something like this:

String.prototype.custom_method = function() {
  // Do custom stuff
};

Array.prototype.custom_method = function() {
  // Do custom stuff
};

So, these are my questions:

  • Do I have to avoid this? Is this a bad practice?
  • Would it be better if I put these methods in a per library/plugin scope?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(3

ㄟ。诗瑗 2024-12-19 06:47:07

鉴于 jQuery 和 Modernizr 做的是完全相同的事情(提供了很多开箱即用的功能,而普通人仍然只利用了 10%),我不认为有什么问题。

肿了吗?也许。理想的情况是只包含您使用的文件(Google 插件方法的伟大之处之一,包括您需要的文件),但是我没有看到比现有文件更大的威胁。

我认为您对它们进行划分是朝着正确方向迈出的一步,因为多个库可能需要它们(没有重复的声明)。但是,如果您真的担心它,您可以进行测试声明设置:

if (typeof foo === 'undefined'){
  function foo(){}
}

但再一次,它需要包含在您发布/构建的每个库中/之上,而不是“包罗万象”的库。

Given jQuery and Modernizr do the exact same thing (provide a lot of out-of-the-box ability, while still the average person only utilizing 10%) I don't see an issue.

Is it bloated? Perhaps. It would be ideal to only include the files you use (one of the great things about Google's approach to plugins, include what you need), however I don't see any bigger threat than what already exists.

I think you compartmentalizing them is a step in the right direction for the sake of multiple libraries maybe needing them (no duplicate declarations). But, if you're really worried about it, you could do a test-declare setup:

if (typeof foo === 'undefined'){
  function foo(){}
}

But once again, it would need to be included in/on every library you release/build, instead of an "all-encompassing" library.

晨曦慕雪 2024-12-19 06:47:07

这是对您所问问题的很好的讨论。

http://perfectionkills.com/extending-built-in- native-objects-evil-or-not/

简短回答:扩展本机类型虽然不是很好,但还可以。像 underscore.js 那样包装它们会更好,因为这样将来就不会发生冲突。

Here is a good discussion of what you're asking.

http://perfectionkills.com/extending-built-in-native-objects-evil-or-not/

Short answer: Extending native types is, not great, but ok. Wrapping them like underscore.js does is better because there is no chance of future conflicts that way.

一身仙ぐ女味 2024-12-19 06:47:07

这取决于观众。如果您向默认类添加或覆盖方法,您将永远无法赢得企业受众。谁知道这会引起什么冲突?看一下 underscore.js http://documentcloud.github.com/underscore/ 一个库,它努力不使用装饰器方法来做到这一点。这对于拥有代码库的用户来说更加友好,除了您的代码之外,代码库可能还包括天知道什么。

但是,如果您的代码确实可以在孤岛中自行运行,那就去做吧。

It depends on the audience. You will never win over an enterprise audience if you add or overwrite methods to default classes. Who knows what conflicts that could cause? Take a look at underscore.js http://documentcloud.github.com/underscore/ a library that strives not to do this with decorator methods. This is much more friendly to users with codebases that may include, in addition to your code, goodness knows what.

However, if your code can assuredly be run by itself, in a silo, go for it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文