使用 Ember 项目运行 Yeoman 和 Rails 的缺点/优点和可行性？

Posted 2023-03-30

技术标签:

【中文标题】使用 Ember 项目运行 Yeoman 和 Rails 的缺点/优点和可行性？【英文标题】：Cons/pros and feasibility of running Yeoman and Rails with an Ember project? 【发布时间】：2013-12-03 11:52:16 【问题描述】：

我正在开发一个 Ember-Rails 应用程序。我以前使用 Yeoman 构建非 ember-rails 应用程序和 js 插件，我希望能够在处理我的 Ember-Rails 项目时实现 Yeoman（尤其是 Grunt 的 livereload）的好处。但是，我不确定 Ember、Rails 和 Yeoman 是否完全兼容，以及它们的角色和职责是否重叠。例如：

依赖管理 - 我了解 Bower 用于依赖管理。 Bower 是否会影响通过 rails 资产管道加载资产的方式？通过 Bower 而不是使用 Rails gem 加载依赖项有哪些优点/缺点？

Livereload - livereload 在单页应用程序（如 Ember 中内置的应用程序）中的功能是否与在多页应用程序（例如，不使用 js 框架的 html 站点）中的功能相同？是单独的模型/视图/控制器重新加载还是整个应用程序通过 Rails 资产管道重新加载和/或重新编译？

现有项目 - 将 Yeoman 集成到现有的 Ember-Rails 应用程序中是否存在陷阱？我们正在生产中运行 Ember 1.3.0-beta 和 Ember Data 1.0.0-beta。如果您有最新的 Ember 构建经验，Ember-auth 和 Ember-data 是否与 Yeoman 兼容？

如果有人有结合 Ember、Rails 和 Yeoman 的经验，或者如果您了解前端和后端如何与这样的堆栈进行比较，请分享您的想法！您是否建议仅将部分 Yeoman 设置（例如 Grunt）与 Ember-Rails 应用程序集成而不是整个 Yeoman？

谢谢。

【问题讨论】：

【参考方案1】：

我不是 Rails 和 Ember 专家，但以下是我对使用 Yeoman 可行性的一般看法：

不使用 Yeoman：可行性

根据我结合 Yeoman 和 Django 的经验，我必须说它开始只在中型或更大的项目中才开始获得回报。在较小的项目中，特别是在截止日期紧迫且对代码质量和技术关注不多的情况下。使用的解决方案（如 Univ. 项目），你可能会更好地坚持使用裸 Rails（手动下载 JS 库并将它们相应地提交到 Rails 项目结构）。

原因很简单：微调全栈框架 (Rails) 和前端框架 (Yeoman) 可能非常耗时。特别是如果 Rails 是由 CoC 原则驱动的。经过一些设置后，它似乎可以工作，但随着项目的发展，您会发现更多的障碍，您将不得不更多地篡改 waaaaaaaay。

我认为这次投资不值得的缺点和事情：

Livereload 我非常喜欢它，一开始我很惊讶，但一段时间后我发现我并没有花太多时间在 IDE 中编辑 HTML&CSS 并在另一个屏幕上观看静态页面自动刷新。在大多数情况下，我仍然需要执行 Alt + tab 并触发一些操作，执行一些单击，所以我是否在中间添加一个 Ctrl+R 键并没有任何区别。在某些情况下，您最好使用本地文件夹映射（Chrome 开发工具）或网络代理（例如：Fiddler）。不过，在某些情况下 Livereload 做得很好，例如，如果您只编辑 CSS，则不需要执行完全重新加载。

至于你的问题：

对我来说，如果它检测到 JS 的变化，它会重新加载整个页面。但也许是因为我使用的是 JetBrains IDE（文件系统缓存）和 CoffeScript（编译为 JS）。

Yeoman 最适合 SPAs。将其设为 SPA，而不是往返应用程序是否可以接受？

Bower - 尝试为 github 项目提供依赖管理 bower 为您的应用程序 所做的基本上是从 github 下载内容。这里没有火箭科学。如果下载的东西的结构是非标准的，Bower/RequireJS/Grunt-bower-install 不知道下一步该做什么，即如何注入所有东西，这样你就不会出错。对于大多数流行的库，bower 可以正常工作，对于高度定制的库，您最终将手动注入下载的内容。应该归咎于没有正确打包有用的 github 项目的人。

此外，我听说有人由于 Bower 问题而提交 bower_components 的工作流程，但从未亲身经历过，也许问题已得到解决。如果是这样，不将第三个库提交到源代码的可能性绝对是一个优势。

注意：正如我上面所指出的，它是 bower 帮助您开发您的应用程序的方式，但是 bower 在某种程度上已经成为前端社区的标准，例如 @987654322 @ 是建立在此之上的，因此它是一个重要的工具。

Rails 组装管道可以获取任意 github 项目吗？是的。它可以将库引用注入您的 html 吗？ Duno，我不是 Rails 人。

发电机 有些可以做得很好，例如为您配置整个与heroku相关的东西。太糟糕了generator-heroku 没有按预期工作（像 2 个月前一样尝试过）。 travis generator 也是如此。在这种情况下，修复很容易，但请参阅下一点。至于 Angular 生成器（我是 Angular 人，不是 Ember 人，抱歉 :-)） - 它只是添加 2 个文件并将它们包含在 index.html 中，此外，如果您使用不那么直接的语法来创建与 JS 框架相关的东西（示例：Angular-related stuff in coffee）生成器很可能不知道它。好的，你可以向生成器提交一个补丁，但是 AngularJS 团队决定在下一个版本中稍微改变一下语法——你明白了吗？ - 再次，看下一点。更重要的是，如果您的项目使用代码由 feature/module（例如管理模块、配置文件设置模块...）而不是按 type 构建的布局（指令、控制器……）特定于框架的生成器将不起作用。

稳定性 Karma 正在迅速发展，Angular、Angular-UI 和大量前端工具、框架也在迅速发展。 Yeoman 很难跟上最近的变化，尽管他们在这里做得很好。

雇用 Yeoman：成为尖端技术

Yeoman 提供了一些非常酷的东西，例如：

起绒

即时编译coffeescript、SASS/SCSS等

CDNifying 当您希望在本地下载库以防离线开发并仍然受益于 CDN 的优点时，这非常有用。如果没有 Grunt，你最终会编写解析 HTML 的脚本

自动 JS/CSS 缩小 Grunt 为你做这件事。您只需正确配置即可。

鼓励前端和后端的分离和低耦合 至于您的问题：我怀疑您是否能够仅使用 Yeoman 来管理 Rails 部分。 Yeoman & sth 中的网络应用程序的一个好方法是：https://***.com/a/19425461/1432478。这是 Django 的，请根据 Rails 进行相应调整。

我的看法

在大多数纯粹基于 Spring MVC、Rails、Django 等的小型项目中，您根本不执行 Grunt 所做的任何事情（因此花费的时间更少）。在某些情况下，必须生产技术先进的前端。例如：最近我发现我的银行账户管理系统并没有缩小 JSes。即使是有趣的 cmets 也保持原样。我没有进行任何匆忙的提款，但我希望他们至少有服务器端验证。 :-)

Yeoman 是一个非常好的解决方案组合，可帮助您完成所有这些琐事。

只使用 Grunt？恕我直言，没有。在应用程序组装方面，Yeoman 是 Grunt。您可以免费获得 Livereload 和其他内容。

如果：

您很幸运，找到了似乎适用于您选择的 Web 框架或设法自行配置的示例配置没有截止日期

那么你应该试一试。

如果您要处理多个项目，则只需将配置复制粘贴到未来的项目中，一次配置的繁琐工作可能会有所回报。但请记住，前端技术正在迅速发展，这就是为什么来自网络的大量样本根本无法开箱即用。