Service or provider with cached data - angularjs

On a server side I have a json file in a dictionary form:
{
"term1": "definition1",
"term2": "definition2",
"term3": "definition3"
}
I'm trying to create a service or provider (one of them is sufficient) which will have a cache of a data from this json file and will be able to use it.
The structures look like:
myApp.service('translateSrv', function() {
this.dictionaryData; // how to populate
this.translate = function(input) {
return this.dictionaryData[input];
};
});
myApp.provider('translateProvider', function() {
this.dictionaryData; // how to populate
this.$get = function() {
return {
translate: function() {
return this.dictionaryData[input];
}
}
};
});
My question is how to populate a dictionary data in this service or provider before the first call of translate() method (in a time of module creation/configuration)? I can't do it asynchronously while first method call.
I want to use one of this structure, among others, in a filter:
myApp.filter('translate', ['translateProvider', function(translateProvider) {
return function(input) {
return translateProvider.translate(input);
}
}]);
I've started recently my work with Angular so maybe my approach is wrong. I will appreciate every hint.

Provider name:
Do not suffix your provider name with 'Provider' since the name you will use to inject the provider in config functions will already be suffixed with 'Provider'
myApp.provider('translate', /*...*/);
// -> injectable provider is 'translateProvider'
// -> injectable instance is 'translate'
Populate the provider in a config function:
myApp.config(['translateProvider', function(translateProvider) {
translateProvider.dictionaryData = { /*...*/ };
});
Advice for performance!
If your translations are static per page view, please consider pre translating your templates.
If you really need it, prefer writing the whole translation js object in an inline script in the document
1 XHR less
no lazy loading deferring application load
Lazy loading
If you really have to lazy load those translations:
Either defer application loading with an external XHR before application load, while keeping the translationData at the provider configuration level,
Or take advantage of the "resolve" part of angular rooting or ui-router, while setting the translationData object on the instance (not on the provider)
How to choose between both?
The first option is quite easy and you won't have to couple application routing with your lazy load constraint.
For the second choice, prefer ui-router and declare an abstract state responsible for handling the lazy loaded data in the "resolve" state property and make other states be children of this abstract state, so that you won't have to add resolve constraints on each state that have a dependency on translations.

Related

Angular 1: $injector can't find a provider dependency when injecting provider inside a provider

My use case is: we have several helper classes, A and B, that are services, A depends on B, and I wanted to make them providers so that they can be used in .config phase.
I followed this SO answer to load a provider inside a provider.
As you can see here, it works:
http://plnkr.co/edit/SIvujHt7bprFumhxwJqD?p=preview
var coreModule = angular.module('CoreModule', []);
coreModule.provider('Car', function() {
//CarProvider.engine
this.engine = 'big engine';
//Car
this.$get = function() {
return {
color: 'red'
};
};
});
coreModule.provider('ParameterService', ['$injector', function($injector) {
try {
var CarProvider = $injector.get('CarProvider');
this.deepEngine = CarProvider.engine;
console.log('deepEngine = ' + this.deepEngine);
} catch (e) {
console.log("nope!")
}
// ParameterService
this.$get = function() {
return {};
};
}]);
coreModule.config(function(CarProvider) {
console.log('configEngine = ' + CarProvider.engine); // big engine
});
This works if I have Car and ParameterService in one file in this order.
However when I split Car and ParameterService into multiple files on disk, or I define ParameterService before Car in the same file, $injector.get('CarProvider') inside ParameterService fails.
How do I fix the issue?
I want to have one provider/service per file and I don't understand what is missing.
The order in which the services are defined doesn't matter during run phase, where service instances are injected. But it does matter during configuration phase, where service providers are injected, i.e. in provider constructors and config blocks.
Providers and config blocks are executed in the order in which they are defined. If Car provider is defined after ParameterService provider or config block, CarProvider doesn't exist at the moment when those two are executed.
To avoid potential race conditions, one module per file pattern should be followed. This allows to keep the app highly modular (also beneficial for testing) and never care about the order in which the files are loaded. E.g.:
angular.module('app', ['app.carService', 'app.parameterService']).config(...);
angular.module('app.carService', []).provider('Car', ...);
angular.module('app.parameterService', []).provider('ParameterService', ...);
Module parts are executed in the order in which the modules are defined in angular.module array hierarchy, from children to parents.
The decision if config block needs its own module depends on what it does (mostly for testing reasons).
It is possible to have providers in different files. You just need to attach them to the first module that you created.
If your markup looks like this:
<script src="coreModule.js"></script>
<script src="parameterService.js"></script>
Then, in coreModule.js, define your module:
angular.module('CoreModule', [])
.provider('Car', function() {
...
}
Remember, the second parameter ([]) tells angular to create a new module.
Then, declare your other provider in a different file, and attach it to your existing 'CoreModule' module:
angular.module('CoreModule')
.provider('ParameterService', ['$injector', function($injector) {
...
}
Notice that we are only passing one parameter to .module(). This tells angular to add your provider to an existing module.
Plunkr Demo

angular translate update translation table

I have created a directive which wraps angular-translate and can also turns into input fields for easy Translating for admin users.
When I update a single translation I don't really want to load an entire translation table from my DB after updating 1 row in the DB, because it seems incredibly inefficient.
My problem is that I can't seem to find anything in the angular-translate API that will allow me to have access to the front-end Cache. I want to modify the translation map directly without having to bother the DB for an entire mapping of my translations after I updated 1 row successfully.
Things that I have tried: $translationCache, $translateLocalStorage, $translateCookieStorage.
Can someone enlighten me please.
Also, as a bonus, I wonder if anyone figured out where they can expose the translation mapping in angular translate.
Note, I don't want the translated values from $translate in the controller because that's already interpolated.
A short view into the source offers no simple way for this. I solved it finally caching a reference from $translateProvider.translations using a own provider:
app.provider('translationHelper', function () {
this.translations = {};
this.$get = function () {
return {
translations: this.translations
}
};
});
In your app do
app.config([
'$translateProvider',
'translationHelperProvider',
function (
$translateProvider,
translationHelperProvider
) {
translationHelperProvider.translations = $translateProvider.translations();
}]);
and use it later like
app.component('myComponent', {
templateUrl: 'views/components/myComponent.html',
controller: [
'translationHelper',
function (
translationHelper
) {
// query translation
var translation = translationHelper.translations['de']["Your.Key.Here"];
// modify translation
translationHelper.translations['de']["Your.Key.Here"] = 'A new value';
}]
});
Alternatively, you can modify the angular translate source and made 'translations' from provider accessible through its $get method.

Ionic & SQLite - Structuring init load with promises

I could not wrap my head around my problem, which I finally understand I believe.
I must initialize user data from a SQLite database, which I am running through the cordova sqlite plugin. My problem is that reading the DB is in an asynchronous deferrable this.loadData function (below). ( I may be "old fashioned", but my major complaint here - why can't DB access be in a synchronous function like all other sane implementations of databases? Without the deferrable it would be straight forward.)
My controller reacts to $stateChangeSuccess where I display a leaflet.js map, that is immediately started by $urlRouterProvider.otherwise('/app/map'); within the state controller.
My problem is that I do not know how to stall the view controller load until all my data is loaded. I tried putting loading the SQLite data into $ionicPlatform.ready so that load would be triggered immediately, but on the device loading the view overtakes the background SQLite thread.
I also tried to load the data within the module during module instantiation by calling this.loadData() at the end. However, the cordova module would not be initialized until then and fail.
What's the best way? Can I make a custom event that would fire when everything is loaded? Should I add a intermediate view after the splash screen that waits out all progress?
Essentially I have to make the whole app loading procedure wait till my data is loaded and do not know how to handle this when SQLite forces one to make all data access a promise. I really would prefer to have a choice of sync / async DB access somehow.
//this is in a module dataService
this.loadData = function(){
if(!myDB)
myDB = $cordovaSQLite.openDB('my.db');
var deferred = $q.defer();
myDB.transaction(function(transaction1) {
transaction1.executeSql('SELECT ID,Data FROM myDB;', [],
function(tx, result) {
console.log(result.rows.length);
var dataJSON = result.rows.item(0).Data;
var dataParsed = JSON.parse(dataJSON);
deferred.resolve(dataParsed);
},
function(error) {
console.log("SELECT failed. Must create table first");
//do other stuff ...
});
});
return deferred.promise;
}
// in my MapViewController the app reacts to
$scope.$on("$stateChangeSuccess", function() {
// init views with the data that should be available now
}
//this is in the starter module
angular.module('starter',[]).config(function($stateProvider, $urlRouterProvider){
\\... states ...
$urlRouterProvider.otherwise('/app/map');
}
As you return a promise, you have to resolve it on then statament, and inside it you can do a redirect.
loadData
.then(loadDataSuccess)
.catch(loadDataError)
function loadDataSuccess(data){
$state.go('map')
}
function loadDataError(error){
//do stuff
}

Angular - reusing code (service or controller)

I'm using Angular to develop commenting functionality for a web app.
Currently there are two sections in the application were a user can comment:
Category
Product
About 90% of the commenting functionality is the same for both sections and as such I would like to make this reusable - i.e write some service or controller that I can reference/use as a base.
So far, my research seems to point to using a factory service but unfortunately this doesn't seem to work (I've spent the whole day running through various tutorials).
It is quite possible that I am over thinking this and making it far too complicated but I honestly don't know which way to turn anymore.
Herewith a quick and dirty overview of what I have so far:
HTML view for the category
Controller for the category (receives data from service and posts data to service in order to bind data to model)
Service for the category (retrieve and stores all the necessary
data)
The product uses the same logic and a lot of the code in the service and controller will be duplicated.
I've merged the two services into one service successfully but I'm having trouble doing the same for the controller.
Do I:
Write a base controller that will communicate with the above mentioned service and that will hookup with the two existing controllers
OR
Write a factory/provider service that hooks up to the two existing controllers as well as the above mentioned service.
If you go the route of using a factory, you could put all the common functionality into its return object and reference that from your controllers.
Factory
angular.module('myModule').factory('CommonFunctions', function(){
return {
foo : foo,
bar : bar
}
function foo(){
console.log('foo');
};
function bar (){
console.log('bar');
};
}
Controller
angular.module('myModule')
.controller('myController', ['CommonFunctions', function(CommonFunctions) {
var vm = this;
vm.foo = CommonFunctions.foo();
vm.bar = CommonFunctions.bar();
}
angular's separation of service types ie:
for specific values
constant
value
(constant for specific values needed before other services are created)
for functions
factory
service
provider
(provider for specific instances when you need a services before other services are created, usually taking advantage of constants)
allow the ability to share data and ways to process that data between controllers and or directives, anything that can be a value can also be a constant, the only difference there being where they can be injected. Similarly any service can be rewritten to a factory or a provider, it is more your specific use case / what your more comfortable writing that would determine which to use, but really the best way to think about it is if you have a value that needs to be shared but is not needed inside angular.module.config then use value, otherwise use constant, now if you have a single function that you want to share, (maybe it processes that value in some way or maybe it just does something else) you should write it as a factory, then when you have a few of those factory's that deal with either that value, or anything else, you can combine them into a service or configure and combine them using a provider. here is a simple example (note i am using the recommended syntax for writing angular services):
'use strict';
var app = angular.module('test.app',[]);
app.constant('configureableValue',{defaultValue:55});
app.value('editableValue',{defaultValue:100,editedValue:null});
app.provider('configureValue',configureValueProvider);
configureValueProvider.$inject - ['configureableValue'];
function configureValueProvider(configureableValue){
var defaultVal = configureableValue.defaultValue,
originalVal = defaultVal;
return {
getValue:getValue,
setValue:setValue,
resetValue:resetValue,
'$get':providerFunc
};
function getValue(){
return defaultVal;
}
function setValue(val){
defaultVal = val;
}
function providerFunc(){
return {
get:function(){ return getValue(); },
reset:function(){ resetValue(); }
};
}
function resetValue(){
defaultVal = originalVal
}
}
// this factory is an example of a single function service, this should almost always be defined as a factory
app.factory('getEditableValue',getEditableValue);
getEditableValue.$inject = ['editableValue'];
function getEditableValue(editableValue){
return function(){
return editableValue.editedValue ? editableValue.editedValue : editableValue.defaultValue;
};
}
// same with this one
app.factory('setEditableValue',setEditableValue);
setEditableValue.$inject = ['editableValue'];
function setEditableValue(editableValue){
return function(val){
editableValue.editedValue = val;
}
}
// now this is an example of a service service collecting the factorys for an object with all the related behavior we need
app.service('editableService',editableService);
editableService.$inject = ['getEditableValue','setEditableValue'];
function editableService(getEditableValue,setEditableValue){
var self = this;
self.setVal = setEditableValue;
self.getVal = getEditableValue;
}
app.config(appConfig);
appConfig.$inject = ['configureValueProvider'];
function appConfig(configureValueProvider){
configureValueProvider.setValue('i changed '+ configureValueProvider.getValue() +' to this!!!!');
}
app.run(appRun);
appRun.$inject = ['configureValue','editableService'];
function appRun(configureValue,editableService){
console.log('before editing: ',editableService.getVal());
editableService.setVal('changed!!!');
console.log('after editing: ',editableService.getVal());
console.log('we changed this in the config func: ',configureValue.get());
configureValue.reset();
console.log('and now its back to the original value: ',configureValue.get());
}
i know thats a lot for a simple example, but there are a lot of features provided by angular, and many ways to use them, hopefully this helps.

Angular JS: why the difference between module.config injection and controller injection?

This is something that I could not figure out from digging into the AngularJS code, maybe you can help solve the mystery.
To show it, I added a service to AngularJS seed project:
function MyServiceProvider() {
console.log('its my service');
this.providerMethod = providerMethod;
function providerMethod() {
console.log('its my service.providerMethod');
}
this.$get = $get;
function $get() {
var innerInjectable = {
name: 'stam'
};
return innerInjectable;
}
}
var serviceModule = angular.module('myApp.services', []).
value('version', '0.1').
provider('myservice',MyServiceProvider);
You can see that this provider exposes $get and a certain 'providerMethod'.
Now, for the injection usage:
If we call config, we can inject the whole class and get access to the 'outer' provider method:
serviceModule.config(function(myserviceProvider) {
console.log('myServiceProvider:',myserviceProvider);
myserviceProvider.providerMethod();
});
But when we inject this to a controller (note the Provider-less name), only the $get return value is exposed:
function MyCtrl1(myservice) {
console.log('MyCtrl1.myservice =',myservice,myservice.name);
}
MyCtrl1.$inject = ['myservice'];
Console output follows as it should:
its my service
myServiceProvider:
Constructor {providerMethod: function, $get: function}
its my service.providerMethod
MyCtrl1.myservice = Object {name: "stam"} stam
Can any one explain the difference? The reason?
many thanks for any thought
Lior
PS: I've seen this technique in angular-ui new ui-router (excellent project!). I need access to the outer provider class to do injection in jasmine and other places - to no avail
A provider is responsible for creating instances. In your example, you created a provider explicitly, but the truth is that every service has a provider, even if it's created automatically for it. [module].service() and [module].factory() are just shortcuts for [module].provider().
[module].config() is run during provider registrations and configurations so you get a change to access providers and do stuff with them. It's a place for configuration of things, hence the name.
From the documentation (http://docs.angularjs.org/guide/module):
Configuration blocks - get executed during the provider registrations
and configuration phase. Only providers and constants can be injected
into configuration blocks. This is to prevent accidental instantiation
of services before they have been fully configured.
Controllers, in the other hand, are instantiated AFTER services have been configured, so you're not supposed to mess with providers anymore. Everything has already been configured. You're ready to get their products now. In this phase, the injector just can't inject providers anymore, just instances (services) created by them.
If you register a service myService...
myModule.service('myService', function() {
// this is your service constructor
});
then you can access its provider, myServiceProvider, in a config function...
myModule.config(function(myServiceProvider) {
// to stuff with your provider here
});
but by the time controllers are being instantiated, you're supposed to ask for services, not their providers, so this will not work...
myModule.controller(function(myServiceProvider) {
...
});
whereas this will be fine...
myModule.controller(function(myService) {
...
});
If you're finding yourself needing to do configuration in a controller, you should stop and rethink the place of responsibilities.
From the Angular mailing list I got an amazing thread that explains service vs factory vs provider and their injection usage. I decided to put it in its own question here
the specific answer is: it is so by design, to allow configuration of the provider at config time.

Resources