Ember.js page with tabs pattern

Question

I have a complicated form I want to display on the issue/:id/edit route. The only way I can display everything I need is using multiple tabs. See included sketch to make the situation clearer:

So what is the 'canonical' way to do this using Ember framework?

My first attempt was this:

Pattern 1: Partials

So all the data is loaded and bound to single tickets/:id/edit route and controller. I was using partials to load different tabs.

This worked fine at first. However as the app grew, the single controller became too small to handle everything. There were dozens of properties, and no clear indication what is common and what belongs to individual pages. Thus, I decided I needed some way to split the logic of individual tabs into their own 'things'.

Pattern 2: Routes

Each tab has its own route and controller. All the data is loaded in the base /tickets/:id/edit route, all the children routes 'borrow' what they need from there.

setupController: function (controller, models) {
    var ticket = this.modelFor("ticketEdit").ticket;
    controller.set("model", ticket );
}

^{An example from one of the child routes}

I'm halfway through to implementing this and I'm already wrestling with problems. I need to prevent people from visiting the bare /edit route. I need to prevent page navigation from ending up in browser history. I need to adjust my breadcrumbs and other widgets.

I can figure all of these out on my own (that's not the point of the question), but I'm not sure it's worth the effort. Bottom line is, route pattern just isn't the ideal fit for what I need. So before I throw more time down the river, I figure I better stop and think if there's a better pattern.

Two candidates come to mind.

Pattern 3: Views

So I can create a separate view for each tab. They would all share TicketEditController, but I could pack them up with some custom stuff so I could ease the load off the common controller.

Downsides: It muddies the water. Some of the widgets I need to display are views themselves and might expect to be instantiated from the controller. Not sure how this will scale as I start adding views within views within views.

Still, this seems like the best fit so far. But am I missing something? Is it worth giving up the route pattern?

Pattern 4: Components

Similar as view. Technically doable, but would require major refactoring of many widgets that presume they have direct access to shared controller. But is there a huge upside to this approach? Not sure.

Pattern 5: ???

???

---

So this is where you come in.

• What do you think about these approaches?
• Which one do you use?
• What are some problems or benefits I'm missing about any/each of these?
• Can you figure out 'pattern 5', or are these all the viable approaches for this problem?

Answer 1

I want to at least drop my thoughts here since you are looking for feedback.

From the identified patterns I favor the first two. The difference I think is bookmarkability/navigation for tabs. I would want to be able to send someone to edit a particular tab via a URL (so I'd favor #2) but it sounds like your requirements are to keep a traditional tabbed behavior (where tabs aren't pages and hitting the back button doesn't take you to the previous tab). So, yes, you could manage the browser history but it sounds like you have other parts (breadcrumbs/widgets) you'd need to address as well so that's up to you to weigh the cost there.

half-baked mixin idea

The main disadvantage of the partials pattern was the monolithic controller. I wonder if you would feel better creating controller mixins, making it clear which properties are for each tab. Perhaps each tab is a mixin:

App.TicketEditController = Ember.ObjectController.extend(
  App.TicketEditGeneralTabMixin, 
  App.TicketEditTextTabMixin,
  ... {

  //common properties

});

misc

You might consider http://discuss.emberjs.com/ as another place to get feedback on this.

Code Review might be another place to get thoughts.