将Angularjs和Rails应用程序分离为独立组件
我想试试Angularjs。 但是，我一直很难决定我应该在哪里找到我的角应用程序。
我在后端使用Rails框架。 我已经看过整个角度应用程序位于assets / javascript文件夹下的教程。
我想知道如果不是生活在assets / javascript文件夹中，我可以将它完全放在我的rails目录之外。 这样，我可以完全分离我的后端和前端。 （这是推荐的吗？）。
我相信资产管道也预编译了很多资产。 如果我要将angularjs资产分开，我是否需要以某种方式预编译资产？
谢谢
您可以使用基于grunt的工作流程：
- 如何使用大量脚本文件管理AngularJS工作流
- http://newtriks.com/2013/06/11/automating-angularjs-with-yeoman-grunt-and-bower/
如果你从一个解耦的前端开始，首先使用模拟，这样你就可以保持在角度内，而不会失去后端和前端逻辑之间的焦点切换。 构建单页面应用程序的一个优点是可以独立于后端api开发它。 有关模拟http响应的信息，请参阅（ http://docs.angularjs.org/api/ngMockE2E。$ httpBackend）。
我一直在研究类似的问题。 有一些很好的工具可以让你将AngularJS直接集成到你的rails资产管道中，如果你只需要一点Angular，它们对我来说很好看。
但是，如果你想要一个完整的Angular前端，也就是一个单页的web应用程序，我想你最终会受到兼容性和一些工具的限制。 我觉得Railsgem不会跟上Angular，所以你会遇到版本冲突。 我也看到越来越多的Angular工具作为独立工具，我非常喜欢ng-boilerplate项目模板。 我也喜欢很多测试工具，比如karma，而我还没有真正找到一种将karma与rails集成的方法。
出于这个原因，我最终决定将两者分开。 最初，我通过创建rails应用程序和单独的角度应用程序（单独的目录）来做到这一点。 我使用ng-boilerplate作为角端的框架。 我写了一个教程 。 这最终有点令人沮丧，我写了一些更多的想法 ，主要的烦恼是我有两个git存储库，让它们保持同步很烦人。 在两个目录中使用IDE也很烦人。 我最终转移到rails和angular在同一个文件夹中，它们看起来很好玩，因为每个使用该项目中的不同目录。
在这个当前的结构中，我正在使用ng-boilerplate附带的grunt设置来缩小所有代码，打包它并运行karmaunit testing。 我还没有确定端到端的测试，但它在我的列表中。 我发现这是一个相对富有成效的工作环境。 我选择的页面，控制器和业力测试用例的结构有一些重复的代码（我选择不考虑它以保持可读性）。 我正计划扩展rails scaffold生成器为我创建javascript框架 – 所以当我创建一个rails rails scaffold时，它也会为我创建一个angularlads人格脚手架。 如果我做这项工作，我会在这里更新。
编辑：我也完成了脚手架工作，它允许rails生成rails模型/控制器等时自动生成angularJS元素。博客文章在这里： http ： //technpol.wordpress.com/2013/09 / 24 /导轨发电机到产生棱角的视图/
我们一直在使用AngularJS和我们的Rails应用程序，我们一直使用Rails ERB模板，但在需要时切换到使用ng指令。
对于上面的设置，我们使用了bower / bower-rails gem，它允许我们使用bower来管理角度包及其依赖性。 我们将它提交到我们的repo，在javascripts目录中，并由Rails资产管道处理。
考虑到我们在ERB模板和Angularjs之间有超过50-50％的视图分割，这种设置对我们来说效果很好。
有关此设置的更多信息，请参见以下链接
分离出api服务（在这种情况下为rails）和前端组件有很多优点。 正如我们为ios / android应用程序所做的那样，角度客户端可以作为一个单独的实体独立存在。 它将是一个静态网站，可以部署在s3或任何静态网站主机上。 它只需要与您的api服务进行通信。 您可以设置CORS以使其成为可能。
这个工作流程的一些优点
- 您可以使用rails-api ，它是rails应用程序的子集。 如果您只是使用rails来构建api，那么拥有完整的rails应用程序提供的所有function是没有意义的。 它的重量轻，速度更快，更倾向于建造API第一拱而不是MVC拱。
- 您可以使用yeoman 角度生成器生成角度应用程序，并充分利用grunt和bower来管理构建（concat，uglify，cdnify等）和依赖项（角度模块）。
- 部署将变得灵活。 你不需要依赖一个来推动另一个。
- 如果您计划更改后端堆栈（例如，rails to play / revel），则无需担心客户端组件。
- 通过拆分前端和Rails后端的开发，您可以将工作分配给两个开发团队，并使应用程序整体保持可扩展性。
这种方法也有一个缺点。 通过将应用程序放在两个单独的存储库中，您无法轻松进行完整的集成测试。 因此，您必须单独测试应用程序。 你可以嘲笑你的apis来测试角应用程序。
我们一直在使用这种方法，并会推荐其他人。 减少依赖性和提高生产力。