-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option for hbs files to be considered route templates and compiled as such #1776
Comments
@mansona I saw the Mainmatter Embroider team, and then lolmaus being assigned and then unassigned on the issue. Is this being worked on? Is there something I can do to help? |
PR #1856 is currently a draft that allows the compilation of hbs route templates as simple templates instead of template-only components. I still have a couple of tests to run to clarify the constraints on the template. |
@BlueCutOfficial Thank you so much, Marine, that looks good! |
This is fixed in @embroider/addon-dev 4.3.0 👍 |
@BlueCutOfficial @mansona Thanks so much! |
Problem description
(I'm taking up the thread from #1756 as requested by @mansona during an Embroider Initiative call.)
Currently, all
hbs
files in v2 addons are considered component templates. If there's no co-located.js
file, they will be considered a template-only component, otherwisesetComponentTemplate
will be called with the template content and the component class.This prevents using route templates (which are also
.hbs
) in v2 addons but, at least in the initial, migration period there exist apps which would need that feature (the need came from an actual client project).On the longer term, using a gjs
ember-route-template
elegantly side-steps that problem (I have a small, working example here), but since it requires the template to be in strict-mode, migrating existing route templates to ember-route-templates is quite an undertaking.In #1756 I provided a working modification to Embroider and a simple Rollup plugin which allowed compiling route templates. However, it had a few drawbacks:
setComponentTemplate
call in the below code snippet), but it still worked!Possible solution
In the same PR, @ef4 suggested to allow "people "o provide globs for including or excluding files from being treated as template-only components.", which I think is a great idea.
On top of that, we'd need to prevent the Babel template-colocation-plugin from inserting the
setComponentTemplate
call in the output. As said above, it doesn't break the template compilation but it makes no sense, and it's superfluous.The text was updated successfully, but these errors were encountered: