I have a service loaded into a component as a provider. This service may return data using Http or it may not, the component should not care. However, it seems that the component itself must include HTTP_PROVIDERS if the loaded service uses Http. This breaks separation of concerns. What am I misunderstanding?
This breaks separation of concerns. What am I misunderstanding?
In order to support instantiating multiple instances of a service (i.e., so all services don't have to be singletons), an Angular app needs a way to specify multiple injectors (not just one). These injectors need to be created and configured in some kind of hierarchy. The component/directive tree, since it is a tree, already has a hierarchy. So Angular uses the (existing) component tree to configure dependency injection. I like to think of it as a sparser "injector tree" that overlays the component tree.
I think it would be more work to define a separate hierarchy for services – we, as developers, would probably have to define and configure another injector tree of some sort.
So instead of thinking of it as "components need to know the dependencies of services" (which, when stated that way, it does sound like we're breaking separation of concerns), I like to think of it more like the following: "when I write an Angular app, I have to configure my providers/dependencies on the injector tree"... and since the injector tree overlays the component tree, I use components to configure it.
But this is not ideal, since if you want to reuse components in a different app, you might need to change the providers arrays (i.e., you may need to reconfigure the injector tree).
In fact, it's better to specify the HTTP_PROVIDERS when bootstrapping your application:
bootstrap(AppComponent, [ HTTP_PROVIDERS ]);
But I agree with you that there are some impacts on having configuration of providers only on components.
The previous configuration will work because of hierarchical injectors.
See this question for more details about hierarchical injectors:
What's the best way to inject one service into another in angular 2 (Beta)?
I have a site that is developed by multiple developers that has multiple pages. Each "page" initializes angular by calling angular.module(etc).
My question is, all pages share some modules, and some pages use specific modules. What is the best practice to achieve this? Do I trust that developers will insert the correct modules that will be needed across the site (i.e. Google Analytics) or do I create one call that is shared my all pages that loads ALL the modules. And is there a way to do both? Such as, initilize the modules that are needed across all the pages and then, load specific modules dynamically on their respective pages.
I would make one global module that is loaded by each individual app, much like modules like 'ngAnimate' are loaded... the global module could then initialize functionality common to all pages, such as Google analytics.
This requires some policing on all developers involved, but this is a good practice via code reviews, etc.
example page:
angular.module('individualPage', [
'globalModule',
'customPageModule'
]).config(
// etc
);
global module:
angular.module('globalModule', [
'googleAnalytics'
]).config(
// etc
);
I have a site that is developed by multiple developers that has multiple pages. Each "page" initializes angular by calling angular.module(etc).
My question is:
All pages share some modules, and some pages use specific modules. What is the best practice to achieve this?
I do not know the best practice when dealing with multiple pages.
IMHO, creating multiple pages is a BAD practice nowadays. I think of
web applications(SPAs) that have different views and states not web
sites with disjointed pages. So if you choose to go the
SPA(single page application) way, you can load all you core/common
modules before the application bootstraps. Views/pages that need
specific modules can lazy load them using something like
oclazyload.
Do I trust that developers will insert the correct modules that will be needed across the site (i.e. Google Analytics) or do I create one call that is shared my all pages that loads ALL the modules.
I can't say much about the question of trust as I do not know your
developers well enough. In general, developers are never to be
trusted, they will do anything that seems to work, high five
themselves and call it a day. The idea is to "Trust but verify", you
don't have to wire tap their phones or read their emails but never
ever take your eyes off the main git or svn repository. Anywhere, If
you were to use oclazyload as I suggested above for a SPA, you would
only need to worry about dynamically loading 'view/page' specific
modules which the developers can configure themselves.
And is there a way to do both? Such as, initilize the modules that are needed across all the pages and then, load specific modules dynamically on their respective pages.
Yes, yes, there is ... SPA approach that I have already outlined
above. I would also recommend using angular-ui-router for the
states and views approach. The idea is to design your application
whilst thinking of it as a desktop or mobile thick client that has
state transitions and so forth.
I have a site that is developed by multiple developers that has multiple pages.
Each "page" initialises angular by calling angular.module(etc).
My question is, all pages share some modules, and some pages use specific modules.
What is the best practice to achieve this?
Do I trust that developers will insert the correct modules that will be needed across the site (i.e. Google Analytics)
or do I create one call that is shared my all pages that loads ALL the modules.
And is there a way to do both?
Such as, initialise the modules that are needed across all the pages and then, load specific modules dynamically on their respective pages.
I would start off by defining what a page is.
Are you talking about a SPA or a more traditional setup a la client transitions between pages with a regular <a href="/page"> and
the server serves the client a piece of HTML?
If the latter is true, then I would urge you to reconsider your underlying approach to your Angular application.
The best (or rather, preferred) way of doing things would be to serve the client a single piece of HTML, and then
transition between pages (from now on I will refer to them as states), by using either ngRoute, angular router (2), or
better yet - ui-router.
For the remainder of my answer I am going to assume that you are in fact working with a SPA.
What is the best practice to achieve this?
As it stands, I would go out on a limb and say that there is no best practice defined for the case you present.
There are a ton of ways to do it, none of which have been officially recommended by the core development team / community standard as far as I'm concerned.
You could go with webpack-angularjs-lazyload, requirejs (angular-requirejs-seed), requirejs (angularAMD), SystemJS among others. Pick your poison of preference!
Do I trust that developers will insert the correct modules that will be needed across the site (i.e. Google Analytics)
or do I create one call that is shared my all pages that loads ALL the modules.
If code contained in an angular.module is required across the site, I would attach it to the main application module.
Such as:
/** Define core functionality that _is_ essential to the application running as expected **/
angular.module('core-module', [ 'route-definitions', 'http-interceptors', 'google-analytics' ]);
/** Inject the core functionality into a bundle module **/
angular.module('main-bundle-module', [ 'core-module' ]);
/** Bootstrap the bundle module as your application **/
angular.bootstrap(/* DOM element */, ['main-bundle-module']);
Now, whenever someone creates a new module for a specific state, they will need to inject said module into the main-bundle-module (barring lazy loaded modules).
As such, the core functionality will always be supplied and available, in your case Google Analytics. In a sense, you just tore down
the trust barrier.
Taking a step back, lets for a moment assume that you are not working with a SPA - and you are in fact re-initialising the
angular application on each page transition (bad move). How would you ensure that the required functionality is always present?
Decorating the angular.module method.
Note: This is not officially supported, be wary of what you are doing. Also it defeats the purpose of modularisation in my opinion, but I'll
showcase the way(s) of doing it.
You could go two ways here I reckon:
Kill the execution of JS if the required module is not a part of the developers module definition.
"Bad cop."
This would catch the 'untrusted developer' in his/her tracks during development, so as to ensure they are following the project standard.
Assist the 'untrusted developer' by automating the task of requiring the module.
"Good cop." (well, sort of...)
This would ensure that the required module is always present, albeit in every module.
"Good Cop"
(function(angular) {
// The always required module(s).
var ALWAYS_REQUIRED = ['cs.core'];
// Keep a reference to the original angular.module function.
var originalFn = angular.module;
// Keep track of registered modules.
var registered = {};
angular.module = function (name, dependencies, configFunction) {
var loaded;
// Ensure that we are always working with an array of dependencies.
dependencies = dependencies || [];
// If the module has not already been registered
if (!registered[name]) {
// Ensure that the required modules are available.
ALWAYS_REQUIRED.forEach(function (required) {
if (dependencies.indexOf(required) === -1) {
dependencies.push(required);
}
});
// Register the module and store it in the registered object for future reference.
loaded = registered[name] = original(name, dependencies, configFunction);
} else {
// Do not re-register the module, simply load it as per 'angular.module('name_of_module')';
loaded = original(name);
}
// Return the loaded module.
return loaded;
};
})(angular);
"Bad Cop"
(function(angular) {
var ALWAYS_REQUIRED = ['cs.core'];
var originalFn = angular.module;
angular.module = function (name, dependencies, configFunction) {
ALWAYS_REQUIRED.forEach(function (required) {
if (dependencies.indexOf(required) === -1) {
throw new Error('You need to add ' + required + ' to ' + name + '\'s module dependencies!');
}
});
return originalFn(name, dependencies, configFunction);
};
})(angular);
That's two ways of killing the trust issue, but in doing so we've introduced code that;
Is not very pretty.
Is definitely not very well tested / battle proven.
Kills modularisation to boot.
And is there a way to do both?
Such as, initialise the modules that are needed across all the pages and then, load specific modules dynamically on their respective pages.
I would say the best way to do so is to:
Take the steps necessary to convert to a SPA.
Write some documentation for all your developers so as to bring them up to speed on the requirements of the project.
Create a standalone module containing the required core functionality and attach it to your ng-app/angular.bootstrap module.
Get ui-router, ui-router-extras and ocLazyLoad to allow for lazy loaded module/state/component definitions.
Have a look at some of the following links for inspiration/ideas on what fits your specific project:
ocLazyLoad-SystemJS-Router by #lookfirst
ng-jspm-seed#futureStateConfig by #kasperlewau
ocLazyLoad#with-your-router
ocLazyLoad+requirejs plunker
webpack vs browserify #stackoverflow
angular + webpack slides
tl;dr
Convert to a SPA.
Bootstrap the application with core functionality supplied.
Write some documentation for untrusted developers.
Better yet, build trust. :)
Lazy load state-specific modules when needed.
You can try browserify to load and build your javascript in single file.
With this you can easy minify the javascript code, and also you can load nodejs modules like events and more, but this is not your question about.
I need to create a module that will be used by different applications.
Each application is using its own set of vars (application name, REST urls, ...).
How do I set inner variable, by the hosting application, in module (or in service)?
Need to init these parameters as soon as possible as the application loads.
Thanks.
In your module have a provider. That way the client application can bootstrap configuration.
Read the "Provider Recipe" section on angular's site for an example of this.
You should use the Provider recipe only when you want to expose an API for application-wide configuration that must be made before the application starts. This is usually interesting only for reusable services whose behavior might need to vary slightly between applications.
I am quite new to NancyFX and investigating its capabilities. Once thing I am trying to figure out is whether it's possible to compose a large site using multiple modules (classes derived from NancyModule) in a way that makes it possible to build routes from several module definitions.
For example, I have the following module, AbcModule:
public class AbcModule : NancyModule
{
public AbcModule() : base("/api/systems/abc")
{
Get["/"] = _ => "ABC API Host";
Get["/domains/"] = _ => Response.AsJson(Domains.All);
Get["/domains/{name}"] = x => Response.AsJson(Domains.All.Single(y => x.Name == y.Name));
}
}
What I don't want is to expose "api/systems/abc". I want this path to be defined in another module (i.e. RootModule) that defines "api/systems" and build a list of available systems at runtime. Then AbcModule is unaware of its container defines all its routes relative to some URL.
Is this possible in NancyFX?
UPDATE. Let me give you an example (and I am open to admit that I've misunderstood something, in this case please hint me where is the flaw). There is a Web service that is going to expose a potentially large collection of services or plugins. Each plugin is responsible for its own resource types and resource structure, but why should it know how its container's routing rules? Imagine that a developer is working with the plugin "music" wrapped in a Nancy MusicModule which defines routes "/rock", "/metal" and "disco". But on a production machine his code is deployed in a Web site where MusicModule becomes a part of a "Hobby" service that defines "music", "sports" and "films" routes. Finally, there is a root module that defines "api" route.
So here is the question: can MusicModule only deals with the routes that belong to its domain, with the rest of the full path be added by other modules, so on a development machine with only MusicModule available "rock" resource can be accessed directly at localhost:xxx/rock, and on a production machine it's exposed from other (chained) modules, so the access path is machinename:xxx/api/hobby/music/rock?
And if this is a bad idea, please elaborate why. What can be wrong with hiding from a module the full route path?
what you are asking for is running at a different root url, where /api/systems/ is not part of your application, but your hosting environment. Nancy does not understand the concept of global root path. It can be done quite easily by intercepting the incoming requests (using a Before hook on the application level) and re-writing the URL of the incoming URL.
I have come across a bit of a problem while using Unity and WPF. The scenario is I have a WPF application which follows the MVVM design pattern. A have a module called ViewKDI. Within this module I have a service called ViewKDIService, the ViewKDIService service utilises another service called UserService.
Every time I load the module ViewKDI I want Unity to return me a new instance of both the ViewKDIService and the UserService.
I have put the below in the shell bootstrapper:
Container.RegisterType<IUserService, UserService>();
In the ViewKDI module I have put the following:
Container.RegisterType<IViewKDIService, ViewKDIService>();
Each time the ViewKDI module loads the ViewKDIService constructor is called. However the UserService constructor is only called the first time, this means that I am not getting a new instance of UserService.
I require unity to give me a new instance of UserService too so that I can manage this session separately from the rest of the application.
Any ideas?
Thanks
Faisal
Unity's default behaviour is to create a new instance of each object each time one is requested, so you shouldn't be seeing this behaviour.
From what I can gather from the source code and MSDN documentation (this is a good read), you can specify a "lifetime manager" object when you register a type to tell Unity how the type should be constructed and cached. Using the TransientLifetimeManager (which essentially does no caching) will cause Unity to re-create the class each time. So try this:
Container.RegisterType<IUserService, UserService>(new TransientLifetimeManager());
... and see if it creates a new UserService each time.