Render components from routes

[michaelrkn]

I hesitated before opening this, because I don't want to be critical of anybody, and because there may already be a plan in place for this. So feel free to close it if it's not appropriate.

As Octane was coming together last year and the call for blog posts went out to inform the 2019 roadmap (which became the 2019-2020 roadmap), I was happy to see many (a majority, I think!) other blog post authors share my excitement for prioritizing a way to render components from a route. But six months after Octane's release, there hasn't been much movement. @NullVoxPopuli has been iterating for a few months on RFCs to move query params to routes (and has told me that another RFC is forthcoming, hooray!), but there hasn't been any movements on the actual rendering of components from routes (#499 and #510).

For new Ember developers, having routes render templates that are backed by otherwise-unused controllers, which are like components but slightly different, is the most immediately obvious wart on Octane's otherwise really modern and straightforward API. Even if we don't have a solution for query params yet, I don't see why we don't move forward on routes rendering components for developers who aren't using QPs, and work on QPs and route-rendering-components in parallel.

It's been so exciting to see new features like the --lang flag and prettier move through the RFC process quickly - I'd really like to see QPs and routes-rendering-components become a priority and get a push from the core team so that we can finally introduce Ember to people without having to make excuses for the otherwise-awesome API.

Thanks for considering this (and for any insight if this is already know and I'm just missing something)!

[rwjblue]

For new Ember developers, having routes render templates that are backed by otherwise-unused controllers, which are like components but slightly different, is the most immediately obvious wart on Octane's otherwise really modern and straightforward API.

Ya, I think I tend to agree with this sentiment (which says a lot about how far we've come 😸).

Even if we don't have a solution for query params yet, I don't see why we don't move forward on routes rendering components for developers who aren't using QPs, and work on QPs and route-rendering-components in parallel.

That certainly is one possible path forward, though I'm not certain that it is the best one. Another valid (IMHO) solution would be to make it possible render a template only component instead of a route template.

Either way, I totally agree that we should be exploring this space now that Octane itself is out the door.

[jelhan]

For new Ember developers, having routes render templates that are backed by otherwise-unused controllers, which are like components but slightly different, is the most immediately obvious wart on Octane's otherwise really modern and straightforward API.

I agree that controllers are very confusing in a framework, which is build with around components and services. I totally agree that we should deprecate them as soon as possible.

But I'm not sure if the route template is an issue. It may just be the way how you describe what components to render for a specific route. It would be a template without a backing class - similar to a template-only component. It would have exactly one named argument so far: @model.

I think that has some advantages over other alternatives that were discussed:

1. The user wouldn't need to learn another syntax to invoke a component. It would be the same template syntax as already used elsewhere.
2. Early adopters can already start to use that pattern right now. All they need to do is not using any controller and not accessing the this context in the route's template. This could be supported by linting rules.
3. It would be small incremental change. It would only require exposing an alternative way to register query parameters, which does not require usage of controllers. Afterwards controllers and access to this context in route templates could be deprecated.

I think the developer ergonomics would be at least okay as soon as the route template is colocated with the route file. By colocating I mean moving the templates from app/templates/ to app/routes/. So having an app/routes/foo.hbs next to app/routes/foo.js.

If support for single-file components is added later we may consider supporting single-file routes as well.

[michaelrkn]

@jelhan Thanks for chiming in! I think these are all worthwhile points for discussion, but I think they're maybe better to discuss on #499. My point in this issue is just that the conversation seems to have stagnated for what I (and many others in the community, via the roadmap blog posts) believe should be a really high priority.

[michaelrkn]

@rwjblue Any progress on this conversation? Anything I can do to move it along?

[michaelrkn]

The newly proposed setRouteComponent moves this forward, woohoo!