

A Year on Angular on Rails: A Retrospective - abuggia
http://www.localytics.com/blog/2014/a-year-on-angular-on-rails-a-retrospective/

======
lucisferre
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](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](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.

~~~
joelrosen
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.

------
dchuk
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.

~~~
joelrosen
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...](https://github.com/FineLinePrototyping/angularjs-rails-resource),
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.

~~~
dchuk
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.

------
equalarrow
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.

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

------
rubiquity
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?

~~~
joelrosen
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.

~~~
craigching
> 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.

------
ffrryuu
How about a Yeoman based setup?

