Consider components with a / (and no -) in their name to be valid.

[tim-evans]

This is a pain point with code organization on our app. We currently have 90 component definitions in /components, and I would like to push some of these components into a folder for organizational purposes.

For a small sample, we have artwork-weight, artwork-piece, artwork-image, artwork-dimensions, artwork-image-approver, as components organized under the artwork vertical.

I'm also willing to hear other organizational strategies (like pods), but I'll need some guidance, and I'm hesitant to move to pods unless there are major positives to this.

For current info on our app, we're on 1.8, upgrading to canary and running on ember-cli

I've been working also on refactoring our application in the process of upgrading to canary, since we were using workarounds and patterns that are no longer supported.

Thanks!

[rwjblue]

This should "just work" with Ember 1.9 and above.

[workmanw]

That's curious, how would the ES6 resolver know where to look for a component in a sub folder? I thought the pods and otherwise functioned by having predictable structures.

Edit: I too would love this feature. We have 30 components currently. And when we replace itemControllers with components we'll have about 50.

[chnn]

I'm also unable to get this to work. Do you still need a dasherized name when a component is nested? For example will moving a reports-list component to reports/list not work because it should be reports/list-something? Or maybe it's the combination of the component pod structure and the slash? (I am on Ember 1.10 and Ember CLI 0.1.12)

Edit: It seems to be the combination of the component pod structure and the nested nature. This structure:

components
└── reports
    └── user-list
        ├── component.js
        └── template.hbs

throws an unfound helper error when using {{#reports/user-list}} {{/reports/user-list}} in a template.

[tobyzerner]

Working fine for me. You do still need a dasherized name.

[rwjblue]

Made a demo repo. See this commit: rwjblue/components-in-subdirs@2109939

[lolmaus]

@workmanw:
That's curious, how would the ES6 resolver know where to look for a component in a sub folder? I thought the pods and otherwise functioned by having predictable structures.

I had the same concern, but @nathanpalmer kindly explained that this is not an issue at all.

[workmanw]

@lolmaus Yea given that the subdirectory is part of the name that makes sense.

One thing I'm still curious about is how this will play out once HTMLBars has shed it's Handlebars templates. Will the following just keep working?

<subdir1/template-only random-string="something passed in the application.hbs">
</subdir1/template-only>

[rwjblue]

Yes.

Also, htmlbars will not stop allowing the usage of mustaches. You will likely always use curlies for things like '{{if}}', '{{each}}', etc.

[workmanw]

@rwjblue Hey thanks for the quick reply!

[tim-evans]

@rwjblue I think you misunderstood. I would like to consider artwork/weight valid. I would like the regex to be dash -or- slash.

[rwjblue]

@tim-evans - Interesting idea. Flagging for discussion at the next core team meeting...

[tim-evans]

Thanks! :3

[stefanpenner]

i like this

[rwjblue]

As do I.

[nathanpalmer]

Seems like this might already be partially supported.

• emberjs/ember.js: Document path based component/helper names
• wycats/handlebars.js: helper names can be paths?

[tim-evans]

@nathanpalmer nope, not yet

ember.js/packages/ember-htmlbars/lib/system/lookup-helper.js

Line 12 in 876eecf

return key.indexOf('-') === -1;

[stefanpenner]

basically this boils down to / isn't valid HTML, in theory we may be able to move to : or some other delimiter. This is a high priority to solve as part of the new angle components, stay tuned.