I have recently started a new project with the most recent ember-cli (v 2.13 as stated in the topic). I am rather set on generating clean semantic html, and as such don't like the extra div.ember-view that the application generates.
Before I could create the app/views/application.js file with following content:
import Ember from 'ember';
export default Ember.Component.extend({
tagName: ''
});
It simply used the component as application view and got rid of the root tag, however it doesn't seem to work anymore. In fact when debugging the resolver "view:application" doesn't show up at all. Is there a new way of solving this situation? Afaik routable components are not exactly in yet, are they?
Granted, my last ember project was using ember-rails (with ember 2.7), now I'm going for a pure ember-cli project, so a few things might indeed have changed.
How can the same effect be achieved now? Is it just a case of adding a special rule to resolver? Or maybe it can be reached otherwise? I learned that ember docs can be rather lacking when it comes to new obscure features...
Views are removed from the Ember 2.0 API. Have a look at this deprecation https://emberjs.com/deprecations/v1.x/#toc_ember-view.
Regarding your question, you can find related discussions in the below url.
https://github.com/emberjs/ember.js/issues/11486
Implementing tagName: '' is not suggested one. In current situation, you can't remove that extra div created by ember application, since ember needs that. What you can do is, you can just apply CSS style to mitigate this,
:root,
.ember-application,
.ember-application>div {
height: 100%;
}
Views are deprecated in Ember > 2.0. The components do generate a div with div.ember-view class added. You can give custom classes to that component using the classNames property and for the component to be other than a div, specify the element to the tagName property.
The extra div can be eliminated using tagName: " " inside each component but you cannot use this.$() to access the component element. The only option is to customize the div created according to our needs.
For application template, I don't think there is any hack to eliminate the extra div created. It might be required by the eventDispatcher.
Related
I am really new to Ember, which I am asked to do and well, love to learn. Basically, the current project uses Gentelella Admin Dashboard. I being trying to get the dashboard to load properly but failed.
After I login, I get redirected to /dashboard/ route, which basically loads the main dashboard interface. Now the problem is I can't click-expand the menus on the sidebar nor toggle the sidebar menu. And the main page is not extended to fill the space, as in our current application.
I know the function init_start() takes care of the resize and the click, which is already added to vendor.js from custom.js but I can't seem to call the function from ember at all.
My latest attempt was using mixins but it failed too:
import Ember from 'ember';
export default Ember.Mixin.create({
activate: function() {
this._super();
init_sidebar();
}
});
then from dashboard.js route:
import HandleTempLoadMixin from '../mixins/handle-temp-load';
export default Route.extend(AuthenticatedRouteMixin,HandleTempLoadMixin, {
});
but still the function is not executed.
I have read that it is best to avoid working with jquery inside ember in SO but I have pretty much many JQuery functions that I cant transfer right now (nor sure why exactly since it says somewhere in the documentation jquery is built into ember itself).
Anyway, what is the best way to initailize the dashboard interface?
From my understanding you have some jQuery stuff that you would like to utilise. I suggest looking into Component's didInsertElement hook and triggering your custom code from there.
You can find more details in here https://guides.emberjs.com/v2.17.0/components/the-component-lifecycle/#toc_integrating-with-third-party-libraries-with-code-didinsertelement-code
In general, try avoid working with view related stuff in Routes. Ember's power comes from strong conventions. Learning where to place your code is crucial.
I have page design, which needs to be displayed into div element with class displayInline:
displayInline: { display: inline-block; }
(there are some makeup designers with hands derived from ...).
Before Ember.js 1.13.x I use hint from Ember.js documentation:
app.ApplicationView = Ember.View.extend({
classNames: ['displayInline']
});
Which correctly produces what I want:
<div id="ember493" class="ember-view displayInline">...</div>
This worked for me now, but generates deprecation and may not work in next Ember.js releases:
DEPRECATION: Ember.View is deprecated. Consult the Deprecations Guide for a migration strategy. See http://emberjs.com/deprecations/v1.x/#toc_ember-view for more details.
How to add custom css class for Application?
I tried searching in Docs and Web, but found no results.
PedroCheckos' answer will work if you're willing to add another element to the DOM. But if you don't want to do that (which I didn't), then that solution doesn't really work well. Unfortunately, the Ember team hasn't provided a solution for this yet. If you look at the view deprecation guide, it suggests workarounds that don't really apply. Until routable components land (likely in 2.1 or 2.2), you're stuck with extending the view as you're doing now.
However, the Ember team has provided an addon that will eliminate the deprecation notice. I suggest using that addon until routable components land, then swapping out your view/controller for a component.
I am found two ways and it's worked in Ember version > 1.13
Use solution from Issue#11906, e.g. change:
app.ApplicationView = Ember.View.extend({
classNames: ['displayInline']
});
to:
app.ApplicationView = Ember.Component.extend({
classNames: ['displayInline']
});
Make right css selector:
body > div.ember-view {
display: inline;
}
I'm trying to create a loading substate for the Application route using the new named substate options added recently, but for some reason, I can't get it to work. Originally, I just had created a simple template, loading.hbs, and it worked automatically, but because of the issues with substates on the application route, some of my UI was still visible. I'd like to correct this now.
I've tried renaming and moving the template around to the following places:
/templates/application_loading.hbs
/templates/application-loading.hbs
/templates/application/loading.hbs
None seem to work though. I don't need any custom routing behavior so the default generated route should do me, unless its a requirement for this to work. Documentation on this feature seems to be sparse. I found the jsbin for this feature and I should be doing it correctly according to it unless there's some issue with ember-cli.
Thank you for any assistance.
DEBUG: -------------------------------
DEBUG: Ember : 1.11.1
DEBUG: Ember Data : 1.0.0-beta.16.1
DEBUG: jQuery : 1.11.2
DEBUG: -------------------------------
I believe that loading.hbs and error.hbs are the application's loading and error substates. Your application-loading.hbs doesn't exist to Ember, which is why it's not working.
As for the additional UI elements: I believe the rest of application.hbs is going to render regardless, so the only suggestion I would have is to nest all those elements one level deeper. It sounds like a big ordeal, but it's actually not that bad:
In router.js:
this.resource('whatever', {path: '/'} function() {
// All your existing routes
});
Then rename application.hbs to whatever.hbs and change application.hbs to just have {{outlet}} in it. This should really change very little else in practice, but it will keep the rest of your UI elements from rendering until loading is complete.
Really should've google it before adding the bounty.
Evidently, this feature is broken. There's a fix already though, just needs to be merged and released.
It looks like you must have a moduleBasedResolver
https://github.com/emberjs/ember.js/blob/06e41ad7ccd28558dd4e651aa070bc06f7757821/packages/ember-application/lib/system/application-instance.js#L153
https://github.com/emberjs/ember.js/blob/b80d66f71d75ad0db9022438ed58a41ac84f45f5/packages/ember-routing/lib/system/router.js#L79
When I look at this value in an ember-cli app it's undefined. Which seems odd because ember-cli is es6 module based.
Then I found this https://github.com/emberjs/ember.js/issues/10756 looks like you can add a route application-loading or hack in moduleBasedResolver onto the registry as a temporary solution.
and
https://github.com/emberjs/ember.js/pull/10944
should fix the issue in the longer term.
It appears you already found this, it did not appear loaded when I wrote this answer. Sorry for the noise.
When you look at a lot of the older (Pre 1.0) Ember code, it seems like the Handlebars helper is {{#linkTo}} (see, for example this SO post from January 2013). Now, the method seems to be {{#link-to}}, based on the official Ember docs.
I can't find any mention of when the helper method changed. But I just tried both {{#link-to}} and {{#linkTo}} in an app using Ember 1.2 and Handlebars 1.1.2 and both work as expected.
Two questions. When did this change occur? I can't find any mention of it in Handlebars changelogs or anything that mentions it. And 2, I assume that since {{#link-to}} is what's currently in the docs, that's the new way. But there's no deprecation notice. Is there a plan to no longer support {{#linkTo}}? If so, when? Which Ember/Handlebars version? For bonus points, link to a an article that talks about that rationale behind this decision.
You wouldn't find anything about link-to in the changelog for Handlebars since it's a helper class for Ember and not included in the main Handlebars library.
According to the blog post for RC8 the old syntax has been "soft deprecated". The old method is marked with #deprecated in the source but doesn't log anything even if used (not even with Ember.ENV.RAISE_ON_DEPRECATION set).
You will also see there that the old one is kept as a straight alias to the new one with no real implementation of it's own.
Ember.Handlebars.registerHelper('linkTo', Ember.Handlebars.helpers['link-to']);
Since they plan to use semantic versioning (as said in the post for the 1.0 release) for their releases they can't really remove this helper until they hit 2.0 though.
The linkTo and bindAttr are changed to link-to and bind-attr in this pull request. The hyphenated form was used, because is more close to web components custom elements syntax. So use the hyphenated form if avaliable in your current version.
From Trek's tutorial:
Your application must have an ApplicationView property. An instance of
this class will be created for you and inserted into the application's
view hierarchy as the root view.
And the tutorial gives this example code:
App.ApplicationView = Ember.View.extend({
templateName: 'application'
});
App.ApplicationController = Ember.Controller.extend();
What is special about ApplicationView and ApplicationController? Is their particular name reserved and must be used by conversion or is there something special about the way the router refers to them?
As I understand it, one of Ember's principals is to eliminate boilerplate code. So I am guessing there is something more to explicitly creating these two views for every app as starting point -- otherwise Ember would just make them for me behind the scene.
To rephrase my question, what makes ApplicationView and ApplicationController special in an Ember application. Do I need to create them explicitly for every app and if so, do I need to name them following a convention?
Note: I am using ember-latest
Ember.js tries to adhere to the programming philosophy of convention over configuration. Because of this some things need to be specifically named and follow correct casing rules. Upon calling App.initialize() your application looks for the property on itself App.ApplicationView. Your app then renders this view, inserts it into the dom and auto-creates an instance of App.ApplicationController, setting it as the render context for your ApplicationView. This means that any properties in your ApplictationController can be bound in your ApplicationView simply by referencing them in the view.
If you call App.initialize() with out an App.ApplicationView or App.ApplicationController ember will throw an error letting you know you must create them.
ApplicationView and ApplicationController are integral parts of your ember application and must exist. Ember is an MVC framework, ApplicationView is your root V, ApplicationController is your root C. It can be tempting to try to use frameworks like ember for just the pieces that you want, but with just a little more work you'll have a much more robust, and easy to use application that trying to cherry pick functionality.