Question

I am trying to understand the best practices for structuring an ember.js application. This slide from tomdale:

https://speakerdeck.com/u/tomdale/p/emberjs-more-than-meets-the-eye?slide=55

has a concise description of how to apportion the application logic. However in trying to follow these guidelines I have finding some problems:

1. The router is growing too large. According to the presentation the router “responds to events from views”, but this results in a lot of code when there are dozens of views.
2. There are a huge number of controllers. In a Rails application the CRUD actions typically reside in the same controller, however for ember apps it seems that there should be a one controller to list records, one to view a record, one to create a record, etc.

It doesn’t feel very DRY because I am ending up with so many files between the controllers, views and handlebars templates that each only have a couple of lines of code.

I am trying to decide if the problem is that I am applying the guidelines incorrectly, or whether these guidelines only work for trivial applications.

Does anyone have any advice – especially on how to manage the growth of the router?

Answer 1

I think that saying Ember encourages too many controllers is like saying Javascript encourages too many functions. Yeah, you can go crazy with proliferation of either. Or you can do the opposite, and have it work exactly as you need. In general, always remember that your app should be exactly as complex as it needs to be, and no more so. You don’t need to use a certain architecture or pattern just because some famous coder guy used it, nor even because it seems to be ‘the Ember way’. Even ‘Universal Good Things’ like Separation of Concerns, MVC, etc. are principles & models which you should try to understand fully then use to the extent that they serve your needs. I think that the ability to selectively break rules and patterns for the right reasons is far more telling a sign of a great hacker than slavish devotion to the dogma of the programming gods. This is a craft, not a religion. (But YMMV. Perhaps there’s a special circle of hell reserved for coders like me. I’m betting against it.)

Specific to Ember, I tend to use Controllers around my data models and/or around a particular user workflow, rather than around each view. Then use Routing/State Managers as the glue between your views, and I generally use Event Managers on views to handle browser events within each view, including sending instructions to the router. So, if I have an app that revolves around, say, Customers and Products, I’ll have a controller for each, just as I tend to do in Rails. This will result in each controller holding more functions and computed properties than some people like to have in one place. It also means that I can’t necessarily reuse my views in another context, because they’re hard-wired to the controller. And yes, this is poor Separation of Concerns. But that’s not an absolute good if it causes complexity that has no payoff.

Also on the subject of Controllers, I think folks particularly tend to proliferate controllers unnecessarily for subsets of your main data model. Say you’ve got a products controller, and you want to store the products that a given user is collecting in a comparison tool. Most people seem to create a new controller for this, but it’s perfectly legit to push these into an additional array or other Enumerable inside of your Products controller or Customers controller, or on your Customer model. This keeps objects that rely on the same functions and properties within a closer scope. The content object in each controller is, AFAIK, just another Enumerable. It has a few special implicit references to the Controller, but isn’t magic. There’s no functional reason I’ve found not to use additional ones too. They work just as well with bindings, with #each, etc.

Similarly, some people just LOOOVE to break their app down into a million files, nest them 15 deep in the file structure, etc. More power to you, if that helps you to visualize the underlying logic, and make it clear to the rest of your team. For me, it just slows me down on projects with only a 1-3 person engineering team. Folks also tend to reproduce the file-based style of other MVC systems they’re familiar with (like Rails), where files are the necessary explicit structure for separating views and other logic objects. This becomes an article of faith and a deeply ingrained habit. But in Javascript MVC, I have found that it often serves no such purpose and is strictly redundant to the implicit design. I tend to use a single, carefully organized file for my entire Ember app (separating it from any other non-library JS), with lots of indentation and nesting where that helps me to visualize the hierarchy. Whatever you do, file-wise, it’s all the same at runtime, provided that you deliver it all to the right place at the right time. With Ember and JS, file structure is for the needs of your team, and nothing else. Calibrate accordingly.

(IMPORTANT CAVEAT: if you do use a million files, you’d better be using a pre-compiler to manifest them all together for delivery to the user, or you’re going to take a huge latency hit on delivering all those files separately.)

(ANOTHER IMPORTANT CAVEAT: with a large team or a rapid daily release schedule like GitHub’s, file-based separation of your logic can make version-control easier than doing lots of merges into the same file, where your merge tool may get confused. Again, this is an issue of managing and monitoring your human processes, and doing merges carefully, rather than a technical requirement imposed by your JS framework.)

(LAST IMPORTANT CAVEAT: Then again, sometimes the difference between a technical requirement and a human/procedural requirement is fuzzy. If you break your developer’s brain, you also tend to have a broken app. So, do what works for the people and processes you have to deal with in getting it built.)

As I said before, YMMV. I’m not a coder God, as you can tell from my reputation score, so you may feel free to disregard me. But I stand behind the idea that you should use only as much complexity, only as much file-structure, and only as many higher-level abstractions (like routing, which may actually be overkill for limited-purpose single-page apps) as serves your needs; and no more.