A Year on Angular on Rails: A Retrospective | Hacker News Reader

A Year on Angular on Rails: A Retrospective

localytics.com

74 pointsabuggia12 comments

We ran into the issue with partial loading as well. The solution was not deploying twice but telling the `.(js|coffee).erb` file with the asset_url links which partials it depended on (this seems like it should be unnecessary and handled automatically simply by using asset_url but it isn't).

The `//= depends_on` directive handles this for you. You can read the issue I filed here for more information: https://github.com/rails/sprockets-rails/issues/95. From the issue it looks like they are working on improving this too.

We also started out with the more granular module design recommended here but actually found it cumbersome. I recalled over-modularity also being problematic when I used to do .NET. I've found (as have many others I talk to) that most projects should just have a "core" (for services, shared directives and controllers) and "UI" (mostly controllers and application specific directives).

In our project we have a "core" which is mostly services and directives and then we break up the rest of the application into separate "app" or "UI" modules which depend on that, these are mostly just controllers. We'll only create other modules if there is an obvious reason to break them out. The easy test is would you package the module up and let it live in it's own repository (maybe as a bower package) in the future. If in doubt, it goes in core.

Another thing that helped a lot was switching to using http://rails-assets.org. This made bower integration of 3rd party dependencies far, far, easier.

I have not had speed problems with Sprockets yet though I've run into them in the past. We are even passing our bower assets through Sprockets so I'm surprised it's running well. I suppose this could be a version thing (we're using Rails 4).

Finally we use Teaspoon to run our tests and I don't bother with AngularJS style integration tests, we test our services mostly and avoid browser automation based testing right now. It is generally cumbersome, slow and unreliable. We try to keep as much logic in the services anyways.

All-in-all, I second the sentiment that using AngularJS with Rails has been great and I actually really like Sprockets/Asset Pipeline for working with it.

Thanks, these are all really awesome pointers!

I agree about having a "core" module, I think we're probably doing a similar thing. Our original problem was just that everything was defined directly on the "core" module rather than on a submodule that was then required by core. Our "app" modules, which like you say are mostly just controllers, then just require the core module.

Aren't you the guys who mixed together Angular with Backbone Models/Collections? Do you still do that?

If so, would love to see you discuss that more.

No, we never did that, although we sort of considered the idea when we transitioned from backbone. We're using https://github.com/FineLinePrototyping/angularjs-rails-resou..., its newly-added native Coffeescript class support is pretty nice. I'd considered talking about data modeling in this post but it was long enough already, and to be honest we're still kind of struggling with coming up with some really solid reproducible patterns here.

ah got it, thanks for the reply.

EDIT: Also, we have your article in /r/angularjs if you want to keep an eye out for questions/comments from the community. We've finally reached a decently active tipping point over there.

This year, for any apps I make, I've decided on no more (or as little as possible) html. Everything is going api and Cappuccino.

Ah, an eccentric, you say. Perhaps. But all these new js frameworks just don't click with me. With Cappuccino, it's not so much the objective-c feel, it's that it's not munging a js framework with html. I design my views like I would real apps - in this case I use XCode (I know, it's not on Linux) and there's a util that translates the xib's into cib's. You can also build the ui in code, which I try to avoid.

I've worked with html a long time and Cappuccino was the first toolkit that made me enjoy making apps that run on the web. So, this is my commitment to myself this year. I'll also be releasing all the server tools on github/gitlab that help facilitate this sort of development (gems and whatnot).

Thanks to the op for the post. Even tho I'm not interested in Angular, still an interesting read.

What backend do you code for the api?

That's a really odd choice. I'm curious how that will turn out since adoption for Cappuccino is really low.

Reading this makes me feel like everything you went through was a pain in the ass but you're so invested now and have learned that you may as well keep going forward with it. Thank you for sharing your experiences though!

My question to you is this: If you were to start a new project, what would you do differently?

We'd do it in Django.

Just kidding. I don't know, that's a pretty hypothetical question. We've heard nice stories about people who split up their frontend and backend into two projects, one completely Angular/Grunt, one completely Rails, where the Rails serves solely as a RESTful API and even user sign in and access checking is done through a remote service. It still sounds like a cool concept, but I'd want to have time to play around with it as a smaller experiment before really investing on a design like that. It would be a big shift in thinking, and again I don't know if it would make our lives easier or harder in the long run.

> where the Rails serves solely as a RESTful API

Honestly I can't imagine not doing that, why wouldn't you? I'm not trolling, making the backend RESTful and interacting with it only via REST calls is a great way to separate your data from your user interface. You can base mobile on this, web, or even legacy applications and reuse your backend service. So if you didn't do that, what model did you follow?

I'll admit, I've flagged this post to read the article later, so if it's addressed in the article, I can read it there.

How about a Yeoman based setup?

Reply on news.ycombinator.com