Pathless nested Routes: good or bad?

In our app we have a primary singleton resource that uses resources from several global lists.

At first we added initializers to the app to load the various global lists, but then we realized another way to do it is to just add nested pathless routes. Then we can lazily load the global resources in SomeResourceRoute->model.

So it looks like this:

@resource 'fonts', path '', ->
  @resource 'arts', path: '', ->
    @resource 'widget' ->
      @resource 'art,
      @resource 'texts', ->
        @route 'new',
        @resource 'text, path: ":text_id"


App.FontsRoute = Ember.Route.extend
  model: ->
        if !App.get('fonts')
          App.set('fonts', @session.query('font'))
        return App.get('fonts')

etc. It makes it easy to setup the lists of resource and their templates.

Are there any downsides to this? In this case the nesting is somewhat arbitrary, and not accessible in the actual url.

This approach did not work in the long run.

I remain at a loss as to how to use Ember to architect an app with mutliple routable views that are concurrently visible. Every approach I’ve tried fails at some point:

  • The “normal” way doesn’t work, because sibling routes disconnect each other’s outlets.
  • The nesting approach as above eventually led to a catch-22 as I knew it probably would.
  • Using {{render}} for the siblings in the template of a parent route and doing nothing in renderTemplate of the routes lets you have multiple sibling routes at one level that dont destroy each other, but than you can’t do much inside them without running into issues. Any routes nested within them are problematic. In some cases it may work if you navigate to a route from the parent, but not if you load a bookmarked route directly.
  • the outstanding connect/disconnect outlet bugs mean trying to do things with named outlets and doing all the rendering in the parent route will cause errors navigating between routes
  • the fact that {{render}} is not dynamic also limits options
3 Likes