使用Rails资产管道与webpack保存资产的利弊是什么?

sta*_*lei 11 javascript ruby-on-rails asset-pipeline reactjs webpack

来自webpacker gem:

Webpacker可以轻松使用JavaScript预处理器和捆绑器Webpack 2.x.x +来管理Rails中类似应用程序的JavaScript.它与资产管道共存,因为Webpack的主要目的是类似app的JavaScript,而不是图像,CSS,甚至是JavaScript Sprinkles(所有这些都继续存在于app/assets中).

但是,也可以将Webpacker用于CSS,图像和字体资源,在这种情况下,您甚至可能不需要资产管道.当专门使用基于组件的JavaScript框架时,这几乎是相关的.

为什么与基于组件的框架使用Webpacker进行资产更相关?如果我使用React,从资产管道对Webpack获取资产有什么不同?

Stu*_*art 12

严格控制资产方面 - 我认为差异不大.但是,我最近将我们的一个应用程序从资产管道迁移到了webpack - 我将尝试分享一些有关webpack在下面有用的知识.

  • 尽管Rails是一种快速移动且动态的语言,但使用最新的前端工具和默认的rails资产处理程序很困难.使用bundler管理JS库是一件痛苦的事.Webpack使维护第三方库变得相当容易.
  • 使用webpack的页面加载使用webpack比默认资产管道更快,因为它在每次刷新期间默认编译文件.
  • Rails目录结构在应用程序的前端和后端之间没有足够的区分.单页应用程序的出现意味着将应用程序的客户端识别为单独的实体而不是后端的一些插件是我们认为非常重要的.前端组件不仅仅是插件.他们是自己的存在.
  • 从视图中分离资产很奇怪 - 视图和资产创建一个存在并且应该位于一个位置,Rails视图更像是控制器上的背包.
  • 热重新加载我们的应用程序前端非常棒.这节省了大量的开发时间.

然而

  • 我们发现它可能因常量配置变化而变化,因此不友好.
  • 它不会在请求上自动运行,就像链轮那样.例如,如果您使用的是webpacker,则需要运行webpacker dev服务器,首先查找文件更改,然后进行编译,然后才能重新加载页面.

webpack主要关注js而不是jpegs,pngs,svgs等这一事实使得rails资产管道和webpack的比较有点令人困惑......

不知道是不是,但我希望这有帮助!