Colocate route+template+controllers

[mehulkar]

In #650, a few people mentioned that colocating routes/templates/controllers in a directory is the main reason they use pods. Making this work natively (similar to colocating components JS/HBS) without pods seems like a good next step.

Not clear what the technical lift is to make this happen, but seems like a natural progression. Requirements:

• works with and without usePods: true
• mix of colocated and non-colocated things works

(Note this doesn't intend to solve all of Module Unification, it is much more simple than that)

[webark]

Would you see this as just covering the existing functionality and how it behaves? (route.js vs index.js) If it is "new functionality", how do you rectify the pattern of components where you have an "index.{js,hbs}" when you have a route and controller at the same level.

Also, does this include components nested in and alongside routes?

[mehulkar]

Would you see this as just covering the existing functionality and how it behaves?

do you mean the functionality that pods provides? I can't say because i have not used that feature and don't know what all it entails.

how do you rectify the pattern of components where you have an "index.{js,hbs}" when you have a route and controller at the same level.

good question. I imagine folders are required and inside it, you have a route.js, controller.js and template.hbs file. I suppose foo/route/index.js is also possible, but i don't think that's valuable.

does this include components nested in and alongside routes?

nope. i think that should remain out of scope.

[webark]

I imagine folders are required and inside it, you have a route.js, controller.js and template.hbs file.

The main dilemma with this is it's
a different convention then what is used for colocated components (which uses either my-component.{js,hbs} or my-component/index.{js,hbs}). now you could do the same with the route/template combo, but then having a my-route.controller.js (or equivalent) is unexpected.

If i where starting a new app from scratch, i'd probably be fine with controllers being separated from the route js|hbs, and follow the convention in a similar and more coherent fashion.

[lougreenwood]

I think one large, but seemingly small benefit of co-location which is often missed is the benefit to pull request reviews, and in turn code quality.

With component co-location, seeing all aspects of a component grouped together (except tests ) makes reviewing easier and in my experience, improves the quality of code review.

It would be nice to have a similar improvement for routers/controllers/templates too 👍

[mydea]

Although not perfect, I could see something like this:

• app/routes/my-route.js
• app/routes/my-route.hbs
• app/routes/my-route.controller.js

That could work the same way as component co-location, so also allow:

• app/routes/my-route/index.js
• app/routes/my-route/index.hbs
• app/routes/my-route/index.controller.js

In our app, we have controllers for about 1/2 of our routes, so I would definitely prefer a solution that also co-locates the controller file. Considering that controllers will/might go somewhat/mostly away at some point, I think it might be OK to have a decent-but-not-perfect solution for them. For us, we only use them for query params.

[webark]

The .controller was more of an example then an actual suggestion. The reasoning behind the "name.js" or "name/index.js" is maintain a consistent import and lookup. Because index is automatically looked up you can get that for free. I think it's best to think of it from that perspective. Like import PostsController from "routes/posts/controller", which feels a little odd.

[mehulkar]

All good points and ideas. I don't think consistency with components and having the same lookup logic is a huge necessity, tbh, but personally, @mydea's suggestion seems pretty good to me. @webark's point about getting /index.js lookup for free would apply to routes, but not controllers, and I think that's ok.

---

In an even more cRaZy idea, what about putting the controller in the same file as the route and exporting as named export? Route+Controller are pretty closely coupled, and personally I think controllers should be moving towards being pretty skinny anyway, and you can always import from somewhere else and re-export! E.g.

// app/routes/foo/index.js (or app/routes/foo.js)
export default class FooRoute extends Route {};

export class FooController extends Controller {};
// or
export { default as FooController } from './foo.controller.js' // or even app/controllers/foo.js

{{!-- app/routes/foo/index.hbs (or app/routes/foo.hbs) --}}
<div>whatever</div>

[webark]

I think that's a great idea! I wonder if that plays well with all the different resolver features as well as the dependency injection that is possible with Controllers, and if that all will play well with Typescript.

With the modernization of the query param logic, and that moving to its own service or the routing service, if they where in the same file, it would be an easy transition.

[tleperou]

The downside to me of this below, as same as component template colocation is the lack a readabily while working a numerous of files:

• routes/login/route.{js,ts}
• routes/login/controller.{js,ts}
• routes/login/template.hbs
• routes/login/forget-password/route.{js,ts}
• routes/login/forget-password/controller.{js,ts}
• routes/login/forget-password/template.hbs

In a matter of consistency, imitate the Component colocation seems a pretty good idea.

For sure, being explicit on the file's purpose is an important aspect of the architecture to me. Adding .controller.{js,ts} is a strong new position in the naming convention that does not empower the screaming architecture.

The idea of @mehulkar to export from the route file gives both, a clear reading of the architecture, and the flexibility to adjust it deliberately by developers.

[webark]

If we do a named export from a route file, how are we discovering these? a loop over every route and look for a named export?

Since we import Controller what would the named export export be? Matching the name with the route would become burdensome à la PostAuthorsController and would serve little benefit as it holds no global scope, and it would be matched up with a name when it is registered. It could be something like RouteController? I don't have a great answer for that.. :/

It would be nice if someone from the core team could weigh in on if using a named export is even a viable option. If it is, that's my vote for the (yet to be written) RFC.

[mehulkar]

If we do a named export from a route file, how are we discovering these?

Good question. I think exporting Controller makes sense.

[mydea]

After investigating ember-strict-resolver a bit, I think both of the options (exporting Controller from the route file, or having a dedicated my-page.controller.js file) would be doable with the resolver.

I tried to setup https://github.com/stefanpenner/ember-strict-resolver in our app to use these rules. The main problem was that there was a build error when having files like these:

• app/routes/debug.js
• app/routes/debug.hbs

Build Error (TemplateCompiler)

EEXIST: file already exists, symlink '/my-app/app/routes/debug.js' -> 
'/tmp/broccoli-96329Dq3bCOsDcC1e/out-433-template_compiler/my-app/routes/debug.js'

I guess this requires a change in ember-cli-htmlbars to handle this similar to component template colocation.

For experimentation, I made it work with a structure like this:

• app/routes/debug.js
• app/routes/debug-template.hbs

Which worked reasonably well. I could detect the presence of a Controller export just fine.

The main downside, from an ergonomics perspective, I could find was that you end up with something like this:

class ApplicationController extends Controller {
  // stuff goes in here
}

export { ApplicationController as Controller };

Which is not super smooth, but OK I guess. It also does feel a bit "magic" - more magic than having e.g. app/routes/debug.controller.js, imho. I would be fine with either solution though, personally.

For reference, the key part was something like this:

class CustomResolver extends EmberStrictResolver {
  hasController(moduleName: string) {
    return this.has(moduleName) && Boolean(require(moduleName)?.Controller);
  }

  _getModuleNameForController(
    fullName: string,
    { prefix, name }: ModuleDefinition
  ) {
    // try colocation...
    let moduleName = `${prefix}/routes/${name}`;
    if (this.hasController(moduleName)) {
      return { moduleName, export: 'Controller' };
    }

    // try index
    moduleName = `${prefix}/routes/${name}/index`;
    if (this.hasController(moduleName)) {
      return { moduleName, export: 'Controller' };
    }

    // try pod
    moduleName = `${prefix}/${name}/controller`;
    if (this.has(moduleName)) {
      return { moduleName, export: 'default' };
    }

    // fall back to default
    return super.moduleNameForFullName(fullName);
  }
}

[jamemackson]

maybe I'm missing something but what is wrong with just using pods? it seems to me that most of the objectives being discussed here are already available.

In fairness, I use a bit of a hybrid approach with pods. I keep services, models, helpers, adapters in the classic structure. Components co-located in the current standard and then I use pods for routes, templates, controllers. I find this to be a very productive layout. The only desire I would have beyond this would be for tests that are logically tied to one of these to be colocated with their counterpart with the probable exception of acceptance tests that cross these logical boundaries but imho those deserve a place of their own in the project tree anyways...