[Feature] Restore separated components: support separate logic and template files (Classic / pre-Octane style)

[nerdy-panda]

Hello Ember team,
First, thank you for providing two component patterns — template-only components and components where logic and template are colocated. This flexibility is very valuable for developers.

When a component’s template and logic are combined in a single file, the file becomes crowded and the code can feel messy. Colocating both the component class and its template inside app/components further clutters that directory and makes organization and maintenance more difficult.

Please consider providing a way to separate component logic and templates, similar to the Classic (pre-Octane) style: a separate class file for component logic and a separate template file under app/templates/components or another directory outside app/components. The separated components option should be supported by the framework so teams can choose the style that best fits their needs.

Benefits

• Improved readability: smaller files focused on a single responsibility.
• Better maintainability: clearer separation makes refactoring and testing easier.
• Structural flexibility: Teams can choose per component whether to use separated files (class and template), colocated files (class and template together in the same folder), or a single file that contains both logic and template.
• Legacy compatibility: eases migration and maintenance of older codebases that used the separated structure.

Thanks again for your work on Ember. This added flexibility would significantly improve the developer experience in larger projects.
Best regards.

[NullVoxPopuli]

Hello! Thank you for opening your issue! <3

First i want to say that we already support what you're asking, you can use co-located files today with no issue. All the benefits you mention are presently available to you, as ember wholly focuses on compat and trying to make migrations as smooth as possible. (Not that you have to migrate, but you will miss out on an increasing number of features)

Secondly, i want to explain why gjs is better for you, and how you can still factor your code in a way that keeps your files smallish

Here is the reading material and research for folks to better understand how we arlived at gjs/gts - trying to solve all the existing problems with the different ecosystems' approaches, and problems folks using colocated components don't even realize they have.

Here is that research (~16k words):

• https://v5.chriskrycho.com/journal/ember-template-imports/
  • https://v5.chriskrycho.com/journal/ember-template-imports/part-1/
  • https://v5.chriskrycho.com/journal/ember-template-imports/part-2/
  • https://v5.chriskrycho.com/journal/ember-template-imports/part-3/
  • https://v5.chriskrycho.com/journal/ember-template-imports/part-4/
  • https://v5.chriskrycho.com/journal/ember-template-imports/part-5/
  • https://v5.chriskrycho.com/journal/ember-template-imports/part-6/

Which resulted in: emberjs/rfcs#779

As for factoring better, some tips:

• split up large templates in to co-located componets, and import { X } from './foo'
• extract js logic in to functions that live in module space -- this has the added benefit of enabling unit testing on complex logic that previously wasn't unit testable
• extract whatever to sibling files and import them with ./the-path

One thing you'll find with gjs is that all the subtle reasons folks made large components are gone now. You have no rough edges pushing you towards large files anymore.

If you want to use ts/glint2/volar, you'll be required to migrate to gjs/gts. Only glint1 supports hbs, and glint1 is in security only mode.

If you do want to migrate your existing code to gjs, we have a codemod:
https://www.npmjs.com/package/@embroider/template-tag-codemod

It uses the same logic as vite's compat mode, so it has the highest amount of correctness a codemod can have.

Hope this helps! Please do let me know if you have more questions/concerns!

And sorry for the brevity. On my phone.