I am currently using ember 1.13. I have two apps which use emberjs. Now I am thinking of integrating these two apps by creating a new route in the first app and display specific route of the second app. Many suggested to use ember-engines,but they need ember 2.10 or higher.Since my application mostly depends on IE 8,I cannot migrate from ember 1.x.
So what should I do? Thanks in advance!!
Cheers!!!
So one approach that would work pre engines is to leverage an addon for the common routes. Your addon will define routes, controllers, and templates as usual with the addons directory. You will also want to define something like addons/utils/router-utils:
// assume we have a single route foo
export function addRoutes(router) {
router.route('foo');
}
router is the this value that ember provides when invoking Router.map. So, within your addon, to allow for "normal" feeling development, you'll want to use this addRoutes function within the dummy app router in tests/dummy/app/router.js:
import EmberRouter from '#ember/routing/router';
import config from './config/environment';
import { addRoutes } from 'addon-with-routes/utils/router-utils';
const Router = EmberRouter.extend({
location: config.locationType,
rootURL: config.rootURL
});
Router.map(function() {
addRoutes(this);
});
export default Router;
Note well, the above router.js file is what Ember 3.8 generates. Yours will most likely differ but the key point is that we invoke our addRoutes function with the anonymous Router.map this value to dynamically add our routes to the dummy app. See this twiddle for an example of adding routes to the router dynamically.
You can now run ember serve from within the addon project and test your routes. Acceptance tests run against the dummy app as well so you're not really constrained by this approach.
Now within your consuming app, you would do the same thing we did in the dummy app to add the routes. This approach, in general, though will require careful engineering to work effectively (a lot of the problems that ember engines solves must be solved by you in some way). Your addon will most likely have to expose a lot of configuration so that you can route outwards from the addon back into the consuming app which will not know about the routes in the consuming app. You'll have to avoid namespace collisions. Sounds fun though :)
Related
This is a very simple and probably easily resolved one.
I have created an emberjs application controller via ember generate controller application from which I want to return some basic computed properties based on the current path to higher level controllers and components. Basically, something like this:
export default Ember.Controller.extend({
entity: Ember.computed('currentPath', () => {
return this.get('currentPath').split('.')[0];
})
});
Oddly enough, I cannot access these computed properties anywhere (they turn out undefined, even if I replace them with a debug string), and in the Ember Inspector's view tree, the application controller is apparently not even present:
I have an older Ember 1.13.0 app, where I'm using the application controller with no difficulty. Have I missed a deprecation here? Or do I need to register the application controller in a specific location?
okay, I solved this differently using injection of the routing service directly into the component (see Component to be notified on route change in EmberJS 2 for details)
I have just started working with ember2.5.1. I wanted to try and create an easy service, and have a component implement it. The problem is that the service is always undefined, and I can't seem to call its methods.
/components/status-component.js
import Ember from 'ember';
export default Ember.Component.extend({
logger: Ember.inject.service(),
actions: {
test() {
this.get('logger').log("testing");
}
}
});
/services/logger.js
import Ember from 'ember';
export default Ember.Service.extend({
log(message) {
console.log(message);
}
});
Other information: I also attempted making routable components, and I'm not sure if that's messing up the services? I essentially have a route pointing to a dummy status-proxy-component.hbs which has the {{status-component}} within it. status-component.hbs is another file.
Any idea why this might not be working? Am I just plain out missing something from services, or is the proxy messing it up?
You must use the get() function to get component properties.
this.get('logger').log("testing");
I had the same problem with Ember 2.4.2; the service was defined in the correct location and would appear in the ember build output, but not in my running ember serve.
The problem turned out to be the hot reloading not picking up on the new service. Killing the server and re-running ember serve allowed the service to work normally.
I've got an Ember-Cli App and would like to create an admin-interface for my application which looks nothing like the page set up in application.hbs.
How do I make the admin-interface independent from that one?
The way I achieved it was to have the base route and, in your case, admin route, kind of what #jcbvm was saying. So the router would look like:
this.resource('base', {
path: '/'
}, function() {
this.path('my-route');
// the rest of the app
});
this.resource('admin', {
path: '/admin'
}, function() {
// admin part
});
I think this can hardly be achieved, my best bet is to either creating a separate application for your admin interface or by moving your core application to a separate route.
When moving your core application to a separate route, you can move the contents of your application.hbs to the template of the new route and your admin interface to the admin route. The only drawback of this is that you will always see the name of your core route in the URL when going to the core application.
You should likely go down the path of Ember CLI addons, see here
I have properties and methods I want exposed to most/all instances of a class (i.e. all but a handful of routes, controllers, whatever). There seems to be multiple ways to accomplish this and I'm looking for guidance for best practices here.
More specifically, I've created a property on my application controller to hold a user session object. I want all other controllers to expose this data as if I had typed:
needs: ['application'],
userSession: Ember.computed.alias('controllers.application.userSession')
directly into the controller.
Further, I want to override all routes (other than the login route and maybe a couple more) implementations of beforeModel to check for the presence of userSession and redirect to the login route if absent.
This is being implemented in ember-cli FYI. So, that being the case, what's the "right" approach here? Do I try to inject these changes via initializers/services? Do I create mix-ins to do this stuff (I'm not a fan of having to remember to do that every time someone working on this does ember g controller that they then have to remember to add the mixin).
Sounds very much like the use of an initializer and a service is the best approach (them being split up makes for cleaner code). The initializer is just the code to load the service, the service does the hard work. The initializer should look something like:
import AuthService from '../services/auth';
export default {
name: 'auth-service',
initialize: function( container, app ) {
app.register( 'service:auth', AuthService, { singleton: true } );
app.inject( 'controller', 'auth', 'service:auth' );
app.inject( 'route', 'auth', 'service:auth' );
}
};
This then injects auth into every controller and route, and you should move the userSession from your application to the service.
My auth service is too big (and in my case: too specific, as it uses Firebase) to be quoting it here. I gave the gist of it in an answer yesterday: Short delay when trying to run redirect with ember route with firebase authentication
And as you mentioned it: people don't strictly need to remember to include mixins as you can override the blueprint that is used when someone does ember generate: http://www.ember-cli.com/#generators-and-blueprints
Say I have a web app - a large, complex, rails app, like an accounting application. I see a use for several single page apps instead of the typical rails round tripping pages. For example, I can see a user better served with an intuitive single page/dynamic app for:
Creating Bank Reconciliation
Creating an Invoice
Filling out a Time Report
etc..
These are all distinct one page apps...
All the ember apps I see are single page and single purpose.
I want to have many single page apps, built with ember. How would that look with respect to:
Routes: I'd have a combination of server routes and client routes. How would that look in Ember? Serve different Ember applications, each with their own application router and routes?
Templates: Would all my "applets" get compiled and pushed down to the client on load? Or would I leverage require.js and load each single page app depending on if they're navigated to?
...
Can anyone help with those two questions?
Thanks in advance!
Routes: I'd have a combination of server routes and client routes. How would that look in Ember? Serve different Ember applications, each with their own application router and routes?
Depends on how much overlap there is in terms of features. For sure you could serve different Ember applications with their own router and routes. In that case you would probably also write a shared library with common base classes and mixins.
An alternative would be to have a single ember application that looks and behaves very differently depending on the route. That's where I would start until you have a good feel for ember and see a compelling reason to split things apart.
Templates: Would all my "applets" get compiled and pushed down to the client on load? Or would I leverage require.js and load each single page app depending on if they're navigated to? ...
Path of least resistance in rails is to use sprockets to compile and package your templates - once compiled they are just javascript. Typically a rails app will bundle all javascript into application.js and include that on load. An alternative would be to split application-specific code and templates into app1.js, app2.js, etc. and load each when the app is navigated to.
I would suggest using a PODS structure and then you can have routes like
/app1/
/route1
/route2
/app2/
/route1
/route2
etc...
If you generate with pods structure you folders e.g.
ember generate route app1\route1
you will end up with a good folder structure that you can split up later, something like:
/app
/pods/
/app1
/route1
route.js
controller.js
template.hbs
/route2
route.js
controller.js
template.hbs
/app2
/route1
route.js
controller.js
template.hbs
/route2
route.js
controller.js
template.hbs