Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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.

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

No branches or pull requests

5 participants