在开发和部署期间我应该使用缩小版本还是常规版本的 jQuery 插件?

发布于 2024-09-10 11:52:17 字数 391 浏览 5 评论 0原文

正如许多人所知,现在找到的大多数 jQuery(或 javascript)插件都可以作为常规格式代码、缩小版本或两者下载。出于开发目的,我喜欢使用插件的非缩小版本,以防我需要设置 Firebug 断点或出于任何原因查看它。

现在,当我打包应用程序并部署它时,为了提高效率,我宁愿切换到插件的缩小版本。我知道执行此操作的唯一方法是手头有两个版本,然后手动更改视图(我使用 MVC)中的所有引用以指向缩小版本,然后打包和部署。理想情况下,我也会缩小(并且可能混淆)我自己的 javascript 文件。

有谁知道使用非缩小插件进行开发(为了可读性)和使用缩小版本进行部署(为了效率)的更好、更有效的方法?有什么文章可以指点我讨论这个问题吗?我对如何处理 javascript 部署还很陌生,可能可以温习一下最佳实践。

谢谢。

As many of you know, most jQuery (or javascript, for that matter) plugins you find these days can be downloaded as either regularly formatted code, minified version, or both. For development purposes, I like to use the non-minified versions of the plugins, in case I need to set a Firebug breakpoint or look through it for any reason.

Now when I package my app and deploy it, I'd rather switch to the minified versions of the plugins, for efficiency's sake. The only way I know to do this is to have both versions on hand, then manually change all the references in my Views (I use MVC) to point to the minified versions, then package and deploy. Ideally I'll be minifying (and maybe obfuscating) my own javascript files as well.

Does anyone know of a better, more efficient way of developing with non-minified plugins (for readability) and deploying with minified versions (for efficiency)? Any articles you could point me to that talk about it? I'm pretty new to how to handle javascript deployment, and could probably brush up on best practices.

Thanks.

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

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

发布评论

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

评论(2

屋顶上的小猫咪 2024-09-17 11:52:17

我倾向于总是使用第三方 JS 的缩小版本,除非我特别需要研究它...在任何情况下,您都可以编写一个 html 帮助器,根据某些配置插入正确的脚本名称(可以是调试还是发布) ...

您最终会得到类似的结果:

<%= Html.IncludeJQuery() %>

时在您传递的脚本上插入“.min”

<%= Html.IncludeCorrectVersionOfScript("jquery-1.4.2.js") %>

或者如果您的所有脚本都遵循相同的约定(.min.js 表示缩小版本),请执行一个帮助程序,在发布更新 :

Html 助手,是 Mvc 的 HtmlHelper 类的扩展方法,您可以使用它来发出 ActionLink、BeginForm、EditorFor 等。您基本上将一个新方法(仅静态)附加到该对象,以便您可以执行 Html.MyMethod...一个帮助器是这样的:

public static class ScriptIncludeHelper
{
    public static MvcHtmlString IncludeCorrectVersionOfScript(this HtmlHelper html, string script)
    {
        if (!html.ViewContext.HttpContext.IsDebuggingEnabled)
            script = script.Replace(".js", ".min.js");
        var tag = string.Format("<script type=\"text/javascript\" src=\"{0}\"></script>", script);

        return MvcHtmlString.Create(tag);
    }
}

请注意,这是非常简化的版本(没有字符串验证等)

现在您可以使用 IsDebuggingEnabled 或 web.config 中的配置或静态配置来定义是否要包含调试版本的最小化版本...

希望这有帮助

I tend to always use the minified versions of 3th party JSs unless I specifically need to look into it... In any case, you could write an html helper that inserts the correct script name based on some configuration (can be debug vs release)...

You would end up with something like:

<%= Html.IncludeJQuery() %>

or if all your scripts follow the same convention ( .min.js for minified version) do a helper that inserts the '.min' on the script that you pass is when in release

<%= Html.IncludeCorrectVersionOfScript("jquery-1.4.2.js") %>

Update:

Html helpers, are extension methods to Mvc's HtmlHelper class that you can use to emit the ActionLink, BeginForm, EditorFor, etc. You basically attach a new method (albiet static only) to that object so you can do Html.MyMethod.... A helper for this would be some like:

public static class ScriptIncludeHelper
{
    public static MvcHtmlString IncludeCorrectVersionOfScript(this HtmlHelper html, string script)
    {
        if (!html.ViewContext.HttpContext.IsDebuggingEnabled)
            script = script.Replace(".js", ".min.js");
        var tag = string.Format("<script type=\"text/javascript\" src=\"{0}\"></script>", script);

        return MvcHtmlString.Create(tag);
    }
}

Note that this is very simplified version (no validation of the string, etc.etc.etc.)

Now you could use the IsDebuggingEnabled or a configuration in your web.config or a static configuration to define if you want to include the minimized version of the debug version...

Hop this helps

娜些时光,永不杰束 2024-09-17 11:52:17

这是 Rails 如何处理它的示例。它可能是也可能不是最佳实践,但完全消除了开发人员的负担。

包含每个环境设置的配置文件:

# resources.yml
# example config file

development:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js

test:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

production:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

根据当前环境将资源解析为一个变量,该变量在应用程序启动时随处引用。

RESOURCES = YAML::parse('resources.yml')[CURRENT_ENVIRONMENT]

然后使用包含在所有页面中的基本布局或模板,而不是让每个视图或页面指定其自己的设置。 <%= Yield %> 表示子视图或页面的输出会到达那里。

# application.html.erb

<!DOCTYPE html>
<html
<head>
    <script src="<%= RESOURCES['jquery_url'] %>"</script>
</head>
<body> <% yield %> </body>
</html>

然后,您只需更改一个键 - CURRENT_ENVIRONMENT(开发、测试或生产)即可触发一切。它对于 API 密钥和所有其他类型的依赖关系也很有用,这些依赖关系已经在环境之间发生或可能发生变化。

This is an example of how Rails handles it. It may or may not be a best practice, but eliminates the load from the developer completely.

A config file containing settings for each environment:

# resources.yml
# example config file

development:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js

test:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

production:
    jquery_url: http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

Parse the resources depending on the current environment into a variable that gets referenced everywhere on application startup.

RESOURCES = YAML::parse('resources.yml')[CURRENT_ENVIRONMENT]

Then use a base layout or template that gets included in all pages, instead of having each view or page specify it's own settings. The <%= yield %> indicates that output from child views or pages goes there.

# application.html.erb

<!DOCTYPE html>
<html
<head>
    <script src="<%= RESOURCES['jquery_url'] %>"</script>
</head>
<body> <% yield %> </body>
</html>

Then you simply have to change one key - CURRENT_ENVIRONMENT (development, test or production) to trigger everything. It is also useful for API keys and all other types of dependencies that already do or could potentially change between environments.

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