gpt4 book ai didi

ruby-on-rails - Assets 中的脚本文件越少越好吗?

转载 作者:行者123 更新时间:2023-12-04 07:40:15 24 4
gpt4 key购买 nike

鉴于:

  • Assets 管道相当复杂(来自 ASP.NET MVC,这
    更复杂):
    How do I associate a CoffeeScript file with a view?
  • 所有 js 文件都将加载到每个页面上,并且每个“准备就绪”
    每个文件中的jquery方法都会被执行

  • 将应用程序的 javascript 分解为“区域”是否更有意义——一个 js 文件用于站点的用户/公共(public)区域,一个文件用于站点的管理区域等等。来自外部站点(jquery,组织中的其他站点)的脚本不会真正适用。

    我看到的好处是
  • 性能:加载一个 80kb 文件比加载 4 个 20kb 文件要快得多,因为 TCP/IP 开销 (source)。在生产中,所有公共(public) js 将被编译到一个文件中并在每个请求中提供服务,但我看到在该文件中包含“管理”代码的缺点。
  • 安全性:脚本文件中可能有一些我不想暴露给未经授权的用户的东西。当然,如果它在脚本中它不安全,但如果我可以最大限度地减少诸如执行数据库维护的 Controller 操作的路径之类的事情的暴露,那就太好了。
  • 开发的简单性:如果准备就绪事件将从每个文件中触发,那么将它放在一个文件中对我来说是有意义的,这样我就不必加载每个文件来查看准备就绪的内容那里。子区域(如管理员)的 js 自然会位于一个单独的文件中,该文件不会来自 Assets

  • 相关: Put javascript in one .js file or break it out into multiple .js files?

    最佳答案

    从其他 javascript 中拆分 admin javascript 听起来是个好主意。

    那篇性能文章绝对是正确的。我还没有看到在一个文件中缓存尽可能多的 javascript 并没有成为性能赢家的情况。即使这些区域不共享 javascript,一次下载一个较大的文件也比多次下载要快。

    如果您有很多库和 1-off 页面特定的 javascript 文件,那么缓存所有库可能是有意义的,只需确保在测试时测量典型用户的缓存命中。

    您可以使用一些模式来最小化负载问题。将事物拆分为模块并仅基于特征检测初始化这些模块对我来说是一种有效的方法。

    例如,如果我有一个 UserInfo模块:

    !function(ns) {
    ns.init = function() {
    ns.setup_login()
    ns.show_user_info()
    }
    ns.setup_login = function() { /* blah-blah */ }
    // ... etc
    }.call(this, this.UserInfo={})

    如果我在与登录相关的页面上有一些 html:
    <div id="user_login">
    <div class="user_info"></div>
    <div class="login_links"></div>
    </div>

    我可以编写一个初始化程序,例如:
    $(function() {
    $("#user_login").each(function() { UserInfo.init() })
    })

    如果没有这种模式,我会编写对 setup_login 的加载调用。和 show_user_info分别地。通常这让我可以根据我在页面上检测到的方面来初始化几个不同的模块,如果你按照它们的依赖关系对这些模块进行分组,通常会进一步减少它。 (我可能已经完成了 User.init -> UserInfo.init 因为也许我可以假设 UserInfo 取决于 User 。)

    关于ruby-on-rails - Assets 中的脚本文件越少越好吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8287643/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com