Ember.js: [glimmer2] looking up components with dots doesn't work

[fivetanley]

Last known working version: 2.7

Given the following file:

//app/templates/very/nested/stuff-yall.js
export Ember.Component.extend()

And the following invocation of the component in handlebars:

{{very.nested/stuff-yall}}

The following error occurs in the console:

Error: Mixing '.' and '/' in paths is not supported in Glimmer; use only '.' to separate property paths: "very.nested/stuff-yall" on line 8.

Since this is a component lookup, it could technically have dots in the filename, or that was at least supported in Glimmer 1. To me this is a semver-incompatible change.

We only had one such invocation where the file path didn't actually include dots, but this seems like a vector for other component lookup stuff to leak into.

Ember Twiddle

[rwjblue]

Using property path notation (via dots) instead of / for referencing nested directories was not intended to work at any point in time (though I do realize/accept that it did). {{foo.bar as a component invocation is specifically reserved for contextual components, and allowing nested directory invocation to mix . and / is massively confusing. I would argue that this is actually a bug that we have fixed.

To me this is a semver-incompatible change.

As with all things it really isn't that simple.

Using {{very.nested/stuff-yall}} to refer to app/components/very/nested/stuff-yall.js was 1) not documented, 2) not commonly used, 3) not supposed to work 😝 , and 4) to support would remove our ability to optimize the more common property path lookup case in Glimmer.

I am absolutely happy to call this out specifically in the CHANGELOG / blog post.

[fivetanley]

I can agree with that. What about the case where the dots are actually part of the file path?

[rwjblue]

Hmm. TBH, I haven't really seen that. Is that something folks have been doing?

[fivetanley]

I've definitely seen it in consulting, and also seems like a big "wat" moment. At the very least the error message should be changed if it _does_ resolve to move the component. But it seems sorta odd to say "you can't have dots in filenames."

[rwjblue]

Well, the error message is specifically saying you can't use / in property paths (which is true), but we can definitely make it better (possibly even looking to see if they have a component in that spot and telling them what to do in the assertion).

[fivetanley]

I guess what was surprising to me is that the error was pretty vague, both about what the problem was and what to do. As I came across this code as we try to prepare for Glimmer 2, I saw "oh they are invoking a component", which at least to me as an end user is not the same as a "property path", which makes me think of trying to resolve a property on an object.

This leads me to the ultimate question though which is what are the resolution rules for {{ }} statements, and is that spec'd out?

[fivetanley]

This is probably less of a big deal than I am making it out to be, but typo'ing filenames was one of my earliest barriers to entry for Ember, and running into this reminded me a lot of that.

[rwjblue]

I saw "oh they are invoking a component", which at least to me as an end user is not the same as a "property path", which makes me think of trying to resolve a property on an object.

Right, that is exactly what I'm saying. A property path is definitely not the same thing as a component invocation, and Glimmer assumes anything with a . in the name is referencing a property path (this even applies to contextual components since they are invoked on a property path too).

We just need to be better about the error. For example, if you have hash or ordered params we know for certain that you meant for this to be a helper or a component, and can give a much more tailored error for that. The only case where we do not really know is the case like {{bar-qux}} (since it is ambiguous without params or hash if this is a helper/component or property path).

[pixelhandler]

@fivetanley Do you think better documentation on naming would help? (In addition to better error message).

[Kilowhisky]

So what is the way forward for people who use the dot syntax? I have hundreds of components and templates that utilize this syntax. I use the syntax because... well i have hundreds of components, things get a little messy.

I'd argue that routes are defined this way so components should be accessible this way.

FYI this is related to this: https://github.com/emberjs/ember.js/issues/14659

[rwjblue]

So what is the way forward for people who use the dot syntax?

Rewrite this:

{{#some-folder.some-path}}{{/some-folder.some-path}}

To:

{{#some-folder/some-path}}{{/some-folder/some-path}}

[JackEllis]

@rwjblue Thanks for your replies here. A night of search & replace for me ;)

[rwjblue]

@JackEllis - Happy to help, and I'm sorry this bit you. 😞

[nadnoslen]

We run an Ember-2.6.3 app that used helpers nested in folders (e.g. app/helpers/formatters/date.js. We used to invoke them as {{formatters.date ...}} or (formatters.date ...) depending on the scenario.

We have NOT upgraded our Ember app or made any changes to our third party libraries. Upon deploying to our staging environment, an npm install and a bower install was triggered...after that happened our app stopped working and was throwing the Cannot read property 'isHelperInstance' of undefined error in our console. I had to debug to discover that our helper {{formatters.date ...}} helper was somehow the issue. To fix we now use the slash-notation for our helper invocations: {{formatters/date ...}} or (formatters/date ...).

In order to reproduce this in DEV, I had to totally dump my node_modules (& bower_components) folders, re-npm install & bower install. Then the error was easier to diagnose in DEV.

I have not been able to determine exactly why this happened, it seems obvious that some sort of Node dependency in the Ember eco-system was recently changed and trickled down into my old version.

[csetera]

We were just bitten by this as well. It turns out that we had just started to move our app to using "dotted" component references since the WebStorm Ember plugin was prompting us to insert the components in this way. We liked the way it looked in the code and that the IDE was going to help us do it that way. In the end, it isn't something to fight too hard against, but just be aware that there is at least one tool out there that is prompting people to insert component references using dotted notation instead of slashes.

[rwjblue]

@csetera - Ahh, I didn't realize that the webstorm plugin was suggesting {{foo.bar.baz derp="huzzah"}}. I believe https://github.com/Turbo87/intellij-emberjs/issues/113 is tracking the issue over there...

[csetera]

Yep. I looked over there to make sure it was registered as an issue and saw the open ticket.

[nadnoslen]

I took a little time yesterday to write a Ruby script that combs through my EmberJS application and replaces MOST (not all) dot-notation paths with slash-notation. It may be helpful to others: https://github.com/cybertoothca/emberjs-component-dot-to-slash-paths

Cheers.

[pixelhandler]

@fivetanley @rwjblue is this still an issue, perhaps we should close; what do you think?

[pixelhandler]

Per our triage policy I'll close this out for now, feel free to reopen if the issue persists on the current release.

• https://github.com/emberjs/ember.js/blob/master/CONTRIBUTING.md#triaging-policy