Skip to content
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

Component rendering fails after upgrading to 1.1.1 #3637

Closed
garth opened this issue Oct 24, 2013 · 12 comments
Closed

Component rendering fails after upgrading to 1.1.1 #3637

garth opened this issue Oct 24, 2013 · 12 comments

Comments

@garth
Copy link
Contributor

garth commented Oct 24, 2013

After upgrading to 1.1.1 (also tried 1.1.0) we get the following type of errors

Uncaught Error: <Ember._MetamorphView:ember815> Handlebars error: Could not find property 'xxxx-xxxx' on object <App.IndexController:ember820>. 

Where xxxx-xxxx is a component name.

Our templates are pre-compiled using the latest ember-handlebars-compiler (https://raw.github.com/emberjs/ember.js/v1.1.1/packages/ember-handlebars-compiler/lib/main.js)

After some investigation it seems that templates that attempt to pass parameters to components get the exception. Without parameters we don't get the exception, but nothing is rendered.

Update

I think that I've tracked down the issue. It seems that when you extend Ember.Application before create then the initializers are not called.

//no initializers are called
var App = Ember.Application.extend({
  //stuff
}).create();

//initializers are called
var App = Ember.Application.create();

Can be fixed by changing to:

var App = Ember.Application.create();
App.reopen({
  //stuff
});

Couldn't find anything in the change log, but if this is an intentional change, maybe it should be documented?

@twokul
Copy link
Member

twokul commented Oct 25, 2013

It looks like (Stef) forgot to pull #3516 into the last beta. It is in the current beta: https://github.com/emberjs/ember.js/blob/v1.2.0-beta.1/packages/ember-application/lib/system/application.js#L679-L697

TL;DR initializers currently do not inherit at all.

Using v1.2.0-beta.1 should be a viable alternative in the short term.

We will bring this up with core, and decide if we need to drop a 1.1.2.

(@stefanpenner + @twokul) paired this comment.

(cc @wycats , @wagenet , @lukemelia et.al)

@wagenet
Copy link
Member

wagenet commented Oct 25, 2013

Yeah, that commit wasn't properly tagged so it didn't get pulled over.

@wagenet
Copy link
Member

wagenet commented Oct 25, 2013

We'll discuss it at the core team meeting tomorrow.

@wagenet
Copy link
Member

wagenet commented Oct 25, 2013

Should be fixed by 1cd63d7. We'll do a 1.1.2 soon.

@wagenet wagenet closed this as completed Oct 25, 2013
@raucao
Copy link

raucao commented Nov 16, 2013

I'm experiencing this bug in 1.2.0-beta.3.

@rwjblue
Copy link
Member

rwjblue commented Nov 16, 2013

@skddc - Could you make a JSBin demonstrating the issue?

@raucao
Copy link

raucao commented Nov 16, 2013

Hmm, the jsbin works, so it looks like a bug in EAK or I'm just using it wrong. I'll investigate further and open an issue for EAK, if it's an actual bug.

Thanks.

@rwjblue
Copy link
Member

rwjblue commented Nov 16, 2013

@skddc - This may be related to #3729.

@raucao
Copy link

raucao commented Nov 16, 2013

Turns out I didn't know that component names can't be single words, and earlier versions didn't complain about it or show deprecations warnings, while it worked fine the way I used it.

@rwjblue
Copy link
Member

rwjblue commented Nov 16, 2013

@skddc - Yeah, components have to contain a dash (to keep in line web component spec see here).

You could manually register a Handlebars.helper with a single word, but it's probably better to go with a dasherized name (to follow conventions).

@raucao
Copy link

raucao commented Nov 16, 2013

Ok, thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants