You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently, @chancancode opened the Component Templates Co-location RFC, which has been added to the Octane milestone. @GavinJoyce argued that since "Octane is a significant milestone for Ember, we'll likely have a moment of significant interest from the wider Javascript community when it's available. If this RFC lands in a similar timeframe to Octane, we'll be able to create much more polished and concise tutorials that will maximise the chances that new people will consider investing more time in exploring, learning and adopting Ember."
If a goal of Octane is to have a level of coherence and simplicity to attract new developers to Ember (and people who tried it earlier and left because of its complexity), there's one obvious remaining area of incoherence in the Ember model: controllers. I worry that if Octane ships with a message of "Ember has modernized and simplified, come try us out!", users will quickly run into controllers and see them as a sign that Ember still carries too much legacy baggage.
@tomdale has said that "the major blocker to removing controllers from the programming model is query params". For the sake of coherence for Octane (and in the spirit of incremental progress that Ember is now embracing), I'd like to suggest prioritizing adding an API for loading a component from a route, even without query params.
Since most users don't need query params, most new Ember users on Octane wouldn't get tripped up on controllers. Existing Ember users not using query params could finally get a way forward to standardize their view layer on components. And after Octane's release, the work to hammer out a query params solution could become a priority, and we could finally move away from controllers.
The text was updated successfully, but these errors were encountered:
You don't need to add controllers as they'll self-generate when not created in the project, but you are right that they are needed for query params. I think ember needs to be cautious on making any more changes with Octane as it's a very large mental shift already. There will be another ember edition that this could be targeted for. Also, this discussion is much larger than just query params. For example; will a route have a co-located template-only component, or will the route be a special component itself, or.?.
The scope of Octane is completely locked down. There are no further changes planned for Octane- but the community roadmap process that we did last year, will be repeated again this year (very soon!). I suggest writing a blog post or gist that lays out your arguments.
Recently, @chancancode opened the Component Templates Co-location RFC, which has been added to the Octane milestone. @GavinJoyce argued that since "Octane is a significant milestone for Ember, we'll likely have a moment of significant interest from the wider Javascript community when it's available. If this RFC lands in a similar timeframe to Octane, we'll be able to create much more polished and concise tutorials that will maximise the chances that new people will consider investing more time in exploring, learning and adopting Ember."
If a goal of Octane is to have a level of coherence and simplicity to attract new developers to Ember (and people who tried it earlier and left because of its complexity), there's one obvious remaining area of incoherence in the Ember model: controllers. I worry that if Octane ships with a message of "Ember has modernized and simplified, come try us out!", users will quickly run into controllers and see them as a sign that Ember still carries too much legacy baggage.
@tomdale has said that "the major blocker to removing controllers from the programming model is query params". For the sake of coherence for Octane (and in the spirit of incremental progress that Ember is now embracing), I'd like to suggest prioritizing adding an API for loading a component from a route, even without query params.
Since most users don't need query params, most new Ember users on Octane wouldn't get tripped up on controllers. Existing Ember users not using query params could finally get a way forward to standardize their view layer on components. And after Octane's release, the work to hammer out a query params solution could become a priority, and we could finally move away from controllers.
The text was updated successfully, but these errors were encountered: