Correctly match runtime classnames to path-derived component names

[barneycarroll]

In trying to work out why people affected by #121 recovered while I was left without the right in-markup hooks, I realise our slightly unorthodox pod hierarchy has splat namespacing (to deal with the fact we're building several apps in one with concerns of a variety of degrees of isolation) eg ./app/{{esotericNamespace}}/components/{{component-name}}.

In any case, the 0.2 betas fail to match hooks in the generated CSS and the markup. Upon debug it was clear that there was a mismatch between the name-generation logic in component-styles and component-names (specifically, this line).

[rwjblue]

👍

[webark]

@barneycarroll I'll look this over when I get into the office, and merge it and cut another release.

[webark]

@barneycarroll in #121 you mentioned that the lookup for the class names was brittle. I agree, but was wondering if you knew of a better way to get this at this time. Not that it prevents this from being merged, but would like it to be a solid as possible. @rwjblue since you chimed in, do you have any ideas to make this more solid? This is one of the areas that would be nice to get a little more solid.

[webark]

@barneycarroll @rwjblue this still seems like an odd fix. Just want to see if either of you have an idea of how the path of the component could be grabbed other then using this._debugContainerKey to make it less brittle. If there is not a better way, that this is just the way it is, could you add a comment about revisiting this at a later date when there is a better way? I thought I saw an rfc about it, but can't find it upon looking. all I found was emberjs/ember.js#10742 which was an rfc hasn't been linked to it yet.

[barneycarroll]

Thanks for coming back to this @webark. The thread about beefing up _debugContainerKey is reassuring. It is an odd fix for a very weird piece of logic hooked onto a very tenuous private API… Let me have a closer look later this morning to see if anything more sensible jumps out at me.

[barneycarroll]

TL; DR: no, not really.

The fact that this fix is weird is a consequence of the fact that the code it fixes is hacky as hell. The patch makes it consistent, but in so doing draws attention to the lack of solid principles behind that (necessary!) consistency. The lack of solid principles can be attributed to the fact that we're using _debugContainerKey as a crutch, and as the linked thread hints, we're not the only people to feel uncomfortable with piggy backing on this undocumented API.

I took at look at ember.js source to see how _debugContainerKey was generated in the first place (in case that hinted at better inferences we might be able to make), but as usual I got lost in indirection, following the call graph and interpolated keys with abstract references up until the point I had no earthly idea what I was looking at, or why. Besides, I suspect @ebryn would have had a good idea of the best way to persist unique class references between build & run time environments.

I thought about taking the pedantic route and refactoring partiallyMashedUpString.replace('components/', '') to a separate module to be invoked in both files — just to make it clear that these things need to match — but in practice this is just one of many hard-coded string replacements without documented reasoning that make up pretty much the whole package. I think doing that would just make it harder to refactor this to a genuinely robust solution (once emberjs/ember.js#10742 finds its way into a public API).

[webark]

fixed with #156

[webark]

Thanks for this @barneycarroll ! glad we found a good solution! Sorry this one had to close.. The merged one is all yours! 😄