I'm trying to find a better way of detecting an ember application than searching for ember-application or window.ember.
Any ideas?
Unfortunately, there's no guaranteed way to detect Ember or an Ember Application. Javascript is fairly malleable, so you could have either on a page and not know where.
To detect Ember, just check for window.Ember. Nothing fancy here, it's pretty much the only way to know (until Ember is no longer global that is). I would say this works in most scenarios (both Ember global and Ember CLI apps).
Detecting an Ember application is much more difficult. The last time I checked, the Ember Inspector does this by checking every property on the window object using Ember.Application.detectInstance(). However, given the gaining popularity of Ember CLI, that will no longer work much of the time. Maybe you could override Ember.Application.create() and keep track of the instances?
In any case, I certainly wouldn't rely on being able to do either of these. It's simply not feasible.
Related
I have an Ember app that uses several 3rd party add-ons. One of these add-ons uses Object.assign() which causes problem in IE11, specifically the error
Error: Object doesn't support property or method 'assign'
I know why this is happening, but I'm relatively new to Ember, and am not sure of the best way to handle/fix this. Based on my research, some options are:
Option 1: use polyfills (?)
I think there may be some additional libraries I can install, or options in Babel to set that will take care of this, but I have not been able to do so thus far. It's unclear whether any of these options would affect code from add-ons anyway, or if they only apply to code in the primary app.
Option 2: extend the add-on component to avoid Object.assign().
Unfortunately, the problematic lines are in the component's init(). When my extended component calls this._super(), the code I'm trying to avoid is run anyway. Is there a way to 'skip' the base component's init() and go straight to Ember's Component.init() (the add-on's _super()) ?
Option 3: ditch the 3rd party add-on, salvage what I can, and make my own component.
Irritating but do-able. At this point, it probably would have been faster to do that from the start.
Option 4: fix the add-on to remove the problem code. My hesitation here is two fold: 1, if this is something that I should somehow be managing within my app, it doesn't seem correct to make the add-on change (though there is definitely a 'best practices' argument to be made here). The bigger concern is that this is a low activity add-on. Even if I submit a PR with the change, I'm not sure how long it will take for a new release.
In the meantime, what would be the recommended practice? Point my app to a local build and then remember to update it to an 'official' version if/when it is released?
I suspect that Option 1, polyfills and/or build settings, is the most correct course of action, but I'm at a loss for what, specifically, to do.
Additional info:
My app was developed with Ember 2.7, and I am in the process of updating it to Ember 3.1. This issue exists in both builds.
You can include polyfill:
// ember-cli-build.js
let app = new EmberApp(defaults, {
'ember-cli-babel': {
includePolyfill: true
}
});
I am trying to move an application from using tornado templates (to be more accurate, it's jinja with an adapter) to ember.js.
It is my understanding that ember.js has very strong opinions on how to compose the final rendered product. In practice, it seems that the whole application must be generated from ember templates on the client side. The server side just provides data in REST format.
Is it possible to have ember work and take control only on some parts of a page that is mostly rendered by tornado templates (a la jquery plugins), or do I have to completely switch to ember?
Welcome, glad you're looking hard at Ember! You're right, Ember has definite opinions on how things should work :-) Despite that, it is indeed doable to migrate over in chunks.
You have a few options on how to handle this.
1. Build out from a single div on a page
You can see this in action on the builds page on the main Ember site (which is a small Ember app). Source for it is available here: https://github.com/ember-learn/builds/
Of interest is the fact that you can define the rootElement that you want Ember to render in to (see https://github.com/ember-learn/builds/blob/master/app/app.js although we should actually move that line to the config file). Once you have Ember on the page it is then possible to have it both interact with external Javascript or to have external Javascript call in as needed.
2. Sprinkle Ember components on to a page
If you need Ember to control multiple parts of the same page, you may want to look at https://github.com/mitchlloyd/ember-islands That addon is designed to work with server-rendered pages, so may not fit your setup. But it's another example of how to refactor in.
3. Use the new GlimmerJS (alpha)
You could also start refactoring into Ember using the newly announced GlimmerJS. The goal for this library is to allow folks to sprinkle in Ember and then as they need page routing and other aspects of Ember, allow them to switch over. So it may fit what you are after.
Note however that the GlimmerJS layer (on top of the Glimmer vm) is still quite new. What is there works well, but much of the Ember polish is still being added. So shipping to production could take some work ...
I am writing a new big project with ember latest version and I don't get any deprecation in console. does that means it will work without major change for glimmer release.
Is there any design patterns or best practices should i follow to ensure it will work without any change after glimmer release ? (I know only DDAU( data down and actions up principle) )
I assume you talk about Glimmer2, because the current ember rendering engine is already Glimmer.
And you don't have to do anything specific. Just keep away from private API's.
As long you just use public API's Glimmer2 should just drop in, as well as Glimmer1 did. Glimmer2 is (probably) not a breaking change, so even deprecations of public API's should not break it. Still try to avoid any deprecations.
This is more of an exploration question.
We have been using breeze.js in our projects for a while and have been quite satisfied with it; it ties nicely into concepts we already know and use (change tracking, metadata, backend agnostic...)
Now we are evaluating the possibility to move our front-end from backbone/marionette/knockout stack to ember.js (which seems to be more of a complete framework than a "pick-only-what-you-need" approach in backbone). We are exploring to possibility to keep using breeze.js as our data management layer on the client-front.
But how can the integration of models returned from the server (server stack: node.js + mongoDB) be done with models defined by ember.js?
A typical ember model definition could be:
var Person = Ember.Object.extend({
Property1: 'foo',
Property2: 'bar'
});
where you can see the extension "Ember.Object.extend"
Breeze.js upon receiving data from server attach a AspectEntity to them (and if Knockout is defined, wrap properties in observables ). How could returned objects somehow be "transformed" into ember.js objects?
Maybe the way we approach this problem and the way we think about this integration is totally wrong or that we should entirely reject this "ember-breeze" combo. From google search we have not found cases where breeze is used with ember.js or some guidance. That is why we come to the stackoverflow community: is it possible? what are the possible pitfalls to look ahead?
There does not seem to be much in the way of existing solutions. The Breeze.js User Voice has some 2-year-old issues that never got much traction; support from that library does not seem to be imminent.
I would recommend exploring Ember-Data as your data management layer. It supports many (if not all) of the concepts you mentioned, and it's the default recommended data library for Ember applications.
That said, as far as trying to make Breeze.js work, you could probably take the objects returned from Breeze and turn them into Ember.Objects using Ember.Object.create, but you'd have to build a layer between Breeze and Ember that essentially serializes between Breeze objects and Ember objects in both directions.
Just in my reading over the last few days I've found at least three different extensions offering data store support for Ember: ember-data, sproutcore-datastore, ember-ezdata, and I think I might be missing one.
This range of options gives rise to several questions.
Obviously ember-data is the "official" extension, but it's also pretty heavily fenced with qualifications ("This isn't ready for production") from the core team.
How should I compare and evaluate these options?
In the SproutCore 1.x series, development was usually done with fixtures, and the data source wired in later. Can any of these options support that sort of workflow? Can I load some production data this way (might change with release versions, but not user-editable) and other data from my back-end data source?
ETA: Here's a related question.
Personally, I'm expecting big things from ember-data, but it does seem to have a little way to go to be "production ready".
When I started using Ember, the ember-data project had just begun, so I decided to create a simple persistence layer of my own. I ended up with ember-rest, which is a pretty thin layer over jQuery.ajax(). You can see it in use in this Rails example. By the way, you can load JSON data directly into ember-rest without hooking into a backend.
I'm under the impression that sproutcore-datastore is no longer maintained. I've never tried ember-ezdata.
Another worthwhile option to check out is ember-resource.
I hope this is enough to get you started.