准备写一个与 Angularjs 相关的的 Rails Gem 包,来让 Rails 下的 Angularjs 开发更爽。
所以想问问大家对目前的 Angularjs 相关的 Gem 有用过哪些?有哪些不满?
我一直用 angularjs-rails
这个 Gem 来开发 Angularjs 类应用,只能说是刚刚够用。很多东西需要从零开始:
所以,想进一步提高 Rails 对于复杂前端的适用范围,让 Rails 开发更爽一点。
想了解大家对 angularjs 使用过相关 Gem 的感受,增加一些更 cool 的需求点,让 Rails 开发更爽一点。
如果要用到 Angular/Ember 这种量级的框架,我就不选择整合进 Rails 了,而是直接分离,这样最爽。 不过最近有一个新出的东西,好像叫 Webpack 吧如果没记错的话,挺酷的,貌似可以让整合变得很爽。
@nightire 你说的分离是指怎么分离?代码直接分离成两个项目还是?
我个人的意思是,从前后端上逻辑是分离的,但利用 Rails 的 Asset Pipe 来进行打包,Webpack 我粗看了一下,跟 Asset Pipe 打包功能上是重合的。在依赖处理上跟 Angularjs 是重合的。
直接
source 'https://rails-assets.org'
gem 'rails-assets-angular'
gem 'rails-assets-angular-animate'
gem 'rails-assets-angular-bindonce'
gem 'rails-assets-angular-cookies'
gem 'rails-assets-angular-faye'
gem 'rails-assets-angular-i18n'
gem 'rails-assets-angular-loading-bar'
gem 'rails-assets-angular-mocks'
gem 'rails-assets-angular-mousewheel'
gem 'rails-assets-angular-resource'
gem 'rails-assets-angular-route'
gem 'rails-assets-angular-sanitize'
gem 'rails-assets-angular-touch'
generator 一开始自己写,最近也不怎么用了,反正前端代码越少越好
测试用teaspoon
CSRF 替换为 angular 的方式
class ApplicationController < ActionController::Base
after_action :set_csrf_cookie_for_ng
def set_csrf_cookie_for_ng
cookies['XSRF-TOKEN'] = form_authenticity_token
end
def verified_request?
request.headers['X-CSRF-Token'] = request.headers['X-XSRF-TOKEN']
super
end
然后好像没啥坑了吧,想不起来了
#2 楼 @lyfi2003 我说的分离就是完全分离成两个项目,使用 API 通信,弃用 Assets Pipeline。前端用自己的一套构建工具。
关于 Webpack 你谈到的两点,的确都有重合之处,但是 Webpack 不是那么简单的东西,可能你没有做过很大规模很重的前端开发吧,angular 并非一切,assets pipeline 对于现代前端开发也并非最理想的构建工具。就那你说的 DI 举例,angular 的 DI 是它自己内部的一套机制,但是大型的项目除了 angular 就能完全不用别的啦?其他的组件一样要考虑 dependencies management,要考虑版本控制/更新,要考虑自动化构建等等。Ruby 的 gems 可以有 bundler 来管理版本依赖等问题,前端的东西怎么搞?总不能样样都是直接 copy 进来吧?当然你也可以直接把 npm/bower/grunt 这一套直接整合进 rails 项目架构里,但是那样太乱了,项目一大就会让人头疼。再比如要使用 ES6 的新特性,assetspipeline 现在能做这个转换不?我不知道哦,angular 可是就要进入 v2,全面使用 ES6,但是在 ES6 普及之前,它还是要依赖前端做一个 transpiler,你要真想大而全,那就还得搞个 gem wrapper。
总而言之,前端开发现在已经有了一整套完善的生态系统,DHH 坚持的那一套不是不行,但总之还是落后了,未来的趋势必然是完全分离。backend 就是 backend,frontend 就是 frontend,何必非要掺合在一起?分开以后 backend 也就不需要负责 view 那一层了,大家都清爽。
当然了,以上都是基于使用 angular/ember 这样的完备的前端框架的前提,目前来说如果要自己整合一套完备的前端框架,倒是可以利用比较成熟的 assets pipeline,因为 grunt/gulp 之类的东西还是有很多 bootstrap 的繁琐工作要做,不过它们也在进化。ember-cli 是一个很好的例子,使用了 broccoli 做构建工具(类似 assets pipeline),整个就是一个 rails 翻版,npm <=> gem,bower <=> bundler,broccoli <=> assets pipeline,grunt/gulp <=> rake,生态完备,但是更适合前端。angular 也有类似的生态系统,不过目前还没有 ember-cli 这么出色的,yeoman 大概算一个吧。这些都是新生事物,但是它们代表着未来。
#3 楼 @comensontin 这样是可以的,就是对新开的项目不够友好,需要自己去定制一些标准。
#5 楼 @nightire OK, 明白你的意思。这确实是一个大型项目的趋势,让各自的人员更专注自己的工作。不过我想,还有更多小型一些的项目,采用 Angularjs + Rails 仍然是一个不错的选择。这时,能更快速构建基本的模块还是蛮有意义的。这是我的思路。
在我看来,一些时候,代码的组织是一个逐渐演化的过程。我的做法一般是 ngapp->rails engines->separately frontend package,在前两个阶段,grunt,bower 和 nodejs 可以被嵌入到 rails 项目,并独立测试。但最后,还是要分开的。
可以用 Yeoman 单独开发前段代码,Rails 只只负责开发 API。到最后用 Yeoman 来打包前段代码,并把相应的打包好的代码,包括 index.html, application.js, application.css 作为静态文件直接放到 rails 项目中的 public 目录下,让 web 服务器直接处理