Salient Soft

I started looking into PWAs as an alternative to the Ionic framework which I have used previously to prototype an offline/online mobile application for my mobile places guide.

My main issue with frameworks such as Ionic was the need for multiple application codebases – one admin application for web based use online (which could also be used on mobile when online), and another application for offline or online use on mobile when actually out in the sticks and looking for a local place that best meets my already specified favourite criteria.

The immediate attraction of a PWA was the simplification due to a single codebase framework. As it is browser based, it can run with any web framework/app architecture and be usable online, and installable for offline use. Some of the main benefits are as follows:

• Allows a single application framework such as Angular or React to be used for a web application which can be used online or installed for offline/online use just like a native app, i.e. can be run as an app from the home screen on a mobile. This allows a single application framework/codebase to be used for all scenarios. This was the key advantage for me – the need for multiple codebases/frameworks when developing an app as a small enterprise is a serious limitation. There is also the potential need for multiple offline applications/frameworks to support all the required platforms, so there can even be a need for maintaining multiple offline native app codebases.
• PWAs are widely supported across browsers/platforms and are a standard.
• A PWA greatly simplifies the installation process. One major issue with web sites which have a mobile app is the need to visit an app store and go through the install process before being able to continue. This really breaks the flow of use.
• Web sites are really keen for users to install their app, as this offers functionality such as offline working and push notifications even when the app is not active/not in use. However, they typically resort to an pattern known as a full page interstitial ad. This interrupts the user, often with a full page overlay, right when they are interacting with content on the web site, in an attempt to force them to install the app – commonly called the door slam antipattern. This takes a number of steps, followed by actually running the app and returning to their previous context. A survey by Google showed that a significant percentage of users just dump the app installation and their web site activity completely when presented with the door slam.
• PWAs have a much more seamless install process which is performed with a click directly within the browser. It does not involve visiting an app store, installing an app, and selecting options/enabling app permissions. Therefore significantly less users are put off by this.

Initial tryout/Proof of Concept

I branched the codebase for my existing Property Details application. This was a good example to try, as it has significant complexity:

• Web application using the Angular framework (v13 at the current time).
• PrimeNG component framework for angular is extensively used, including complex components such as the photo gallery
• Dynamic scripting/script switching for configuration and PrimeNG theme switching.
• Use of the angular APP_INITIALIZER to initialise/configure the app prior to angular bootstrapping, and use of angular/browser polyfills.
• Use of the Webpack module bundler to bundle and install the application

I felt that if I could get this application to run seamlessly as a PWA with minimal effort and changes to the existing code, this would be a valuable proof of concept to justify taking PWAs forward.

My conclusion was very positive – whilst I had a number of technical/learning issues to overcome, I succeeded in getting the property details app to run as a PWA both online and fully offline in Chrome, edge, and Firefox, on both Windows and Android, with minimal code changes. The only code interventions were to add the necessary support for PWAs, which were minimal. None of the existing code had to be modified. I just needed to add a json PWA manifest file, a couple of scripts, and an icon image. I then just needed to modify the index.html page to declare the manifest and call the first of the scripts. Going forward, I will need to try the other PWA features such as background/offline sync, push notifications, and service worker to page/Window to service worker communication. I will also need to make some effort to smooth the app rendering to bring up a page quickly, especially when offline, as the current POC is somewhat jerky on occasion, with some delays on rendering. However, it works reliably as expected.

I also have not looked into the database functionality re offline/online use and syncing. For the database, it is tempting to stick with CouchDB, as PouchDB is available as a wrapper for IndexedDB and could be used for background sync with a CouchDB as I originally planned with my Ionic POC. One issue which needs exploring on this is the availability of CouchDB hosting – my ISP, Zen Internet, use CPanel which does not host CouchdB. If this is an issue I would need to either use IndexedDB with e.g. MySQL at the back end and my own abstraction/syncing between the two, or use continue to use PouchDB still with a MySQL back end – this whole area needs investigation.

I have therefore decided to look into using PWAs further as a replacement for my existing Ionic offline POC/tryout.

Comments Off on Progressive Web Apps

I was getting fed up with the various hacks and switches needed e.g. in Chrome to persuade it to use an ordinary self signed certificate to allow ssl for localhost during local development and testing.

My holy grail was to have seamless self signed localhost certificate support, such that the browsers would not complain at all or need any special hacks, but ‘just work’, and without any nasty warnings in the address bar. I wanted to use the same certificate in a Java Keystore for Spring Boot, as well as with a node http-server for serving webpack bundles. After much fishing around, the following solution worked for me.

Summary of Issues found/solved

1/ You can get a self signed cert to be fully trusted locally if you add it to the local computer’s Trusted Root Certification Authorities Store. For windows this is straightforward with the management console – details below in the steps.

2/ In addition, the certificate needs to have a Subject Alternative Name (SAN) defined as localhost, or Chrome will spit it out with a Common Name error. This is a misnomer – the problem is not with the Common Name, it is due to the lack of a correct SAN. Just setting the Common Name (CN) to localhost is deprecated and will no longer work in Chrome.

3/ The Java Keytool can create a keystore containing a certificate with a SAN, using the ext switch. This is detailed here for Java 7 (see the table under the -ext switch). It also works for Java 8 but I found the above docs somewhat clearer than those for java 8. However, I could not find a way to add multiple SAN DNS references, e.g. for localhost and for www.localhost.

4/ I found a way via this post here to use openssl to create a certificate keystore containing the certificate, which I could then import into a java keystore using keytool. openssl  was able to create multiple SAN DNS entries as required. My previous post here links to this post re setting up a Wamp Server, which links to this page re installing openssl.

5/ A trivial gotcha which I hit initially – once you have created and installed the certificate e.g. in the computer’s trust store as above, make sure that this certificate is also the exact one that you are using with all your web servers – in this case, http-server and Spring Boot.

6/ Once all done and working, I could happily use Chrome, IE11 and Firefox without any hacks or switches for self signed certs, and without any hacky warning on the address bar – just the normal black padlock.

Steps to Implement the Solution.

1/ I created a config file for openssl, e.g. req.cnf, as follows:

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = GB
O = Salient Soft Ltd
CN = localhost
[v3_req]
keyUsage = critical, digitalSignature, keyAgreement
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = www.localhost

2/ I created the certificate and key via openssl using the above config file:

openssl req -x509 -nodes -days 36500 -newkey rsa:2048 -keyout ss-localhost-cert.key -out ss-localhost-cert.crt -config req.cnf -sha256

3/ Import the certificate and key into a PKCS12 store, and then import that store into a java keystore with keytool:

openssl pkcs12 -export -name salientsoftdev -in ss-localhost-cert.crt -inkey ss-localhost-cert.key -out ss-localhost-cert-keystore.p12
keytool -importkeystore -destkeystore salientsoft.p12 -storetype PKCS12 -srckeystore ss-localhost-cert-keystore.p12 -srcstoretype pkcs12 -alias salientsoftdev

4/ Use the Microsoft Management Console to import the above certificate (ss-localhost-cert.crt) into the local computer’s Trusted Root Certification Authorities Store. This post  details how to do this on Windows 10, but Windows 7 was the same.

5/ I used the final keystore for Spring Boot (per details here), and the certificate and key files for node http-server (per details here).

Comments Off on Creating a fully trusted Self Signed localhost certificate

I did an npm-update of  my microapp-fabric-prototype and my microapp-dataview app.

This resulted in the upgrade of

"@angular-devkit/build-angular": "~0.8.2"

to:

"@angular-devkit/build-angular": "^0.13.4",

in package.json. This caused my microapp POC to fail.

When the host Microapp Fabric application receives a menu action from a menu item click, it dynamically creates an angular element in its microapp container; the element contains the target microapp.

This should result in the initialisation of the angular runtime environment for the custom angular element, including initialisation of the IOC/DI environment for the target angular element app. This includes creation of all the required components/services and calling of their various constructors.

Unfortunately, with the later version above, instead of initialising the app-config-service in the angular element, it tried to re-initialise the app-config-service for the host app a second time which caused the whole app to fail.

The precise reason for the issue is not known. Both apps have some services (such as app-config-service) which have the same name, and sometimes when debugging it can cause confusion when trying to navigate the source maps in the debugger.

However, as all the services and components for each app (the main app and any angular-elements) are correctly encapsulated, there is never a confusion between them, even though the script environment is common and not shadowed. (In this demo, we are using a shadow dom for the W3C custom elements/angular elements, but the javascript is not shadowed. This is correct, and allows angular to have a runtime environment which persists across the main app and all the angular elements, and manages them all correctly).

As I have found before, care needs to be taken when upgrading versions – this is quite often not straightforward and needs care to check out dependencies that cause failures. Care will be needed I suspect when upgrading from Angular 6.1.7 to Angular 7!

No Comments »

lite-server is useful when it is desired to serve an application using actual files, in contrast with ng serve which serves everything from memory. A comparison follows:-

ng serve

This uses webpack to build and serve the application entirely from memory. The consequence of this is that any files (such as external configuration files) which are not specifically part of the angular-cli/webpack bundles/built by webpack will not be available/visible when the application is served. Additional script files can be included in the build bundles by adding to the scripts property in .angular-cli.json, but of course if this is done they are not then external to the build.

lite-server used in development mode

Having installed lite-server globally, it can be used in the following way such that file changes are monitored and updated dynamically in the build :-

under linux:-

ng build –watch && cd dist && lite-server

under windows:-

ng build –watch
rem then under a separate command session:-
cd dist
lite-server

lite-server used in production mode

This will do a production build with AOT enabled by default:-

ng build –prod
cd dist
lite-server

No Comments »

Key Goals

1. The primary goal is to completely decouple configuration data from the build deployment. This is a key requirement in an enterprise setting, not least because it is vital that the very same build can be tested and signed off in a number of different development and test environments pointing at different server infrastructure.  If a different build was needed for each environment, there is always the risk of an incorrect build, so technically the final production build has never been tested and could break. A good discussion on this may be found on The Twelve Factor App site here.
2. Upon investigating a pattern for this in Ionic and Angular, I found numerous posts citing different ways around the problem, some appearing quite complex. I was left feeling that this need was not something that had been baked in to the Framework design as a first class citizen – it was certainly not an up front and clear pattern in the documentation. Therefore I wanted a reusable pattern to use as a standard for all my Angular development.
3. I am using angular-cli with webpack, which is the recommended approach. This produces simple static deployment bundles which are web server agnostic – just an html file which loads one or more js bundles, plus assets such as fonts and images. The pattern for externalising configuration aims to fit in with this and makes no assumptions about the ability to build configuration data dynamically server-side or inject configuration related information into the web server. For example, a common pattern when using Apache Tomcat with Java applications is to inject a configuration location as a JVM parameter into tomcat, which is used later server-side to access the configuration dynamically. We make no assumptions here about the ability to do this kind of trick – any such mechanisms (discussed further below) would be an extension to the pattern for a particular server.
4. An important goal of the pattern is that it should be testable, i.e. we use dependency injection to inject configuration into the classes that use it, (in our case via a service). This allows unit tests to inject test configuration as required.
5. The pattern also supports offline use e.g. in an Ionic application. If, as some solutions advocate, the configuration was loaded via an HTTP service in javascript code, this would not work offline with Ionic. The challenge that remains is how and where the configuration would be located in an Ionic deployment, but that is a question for another day and further invesigation.

Solution Overview

1. After a fair amount of investigation I settled on a fairly simple pattern as per this post here. This stackoverflow comment refers to the same technique.  I adapted the technique for my situation – the key points are as follows, and a code sample is shown below.
2. The basic idea is to load configuration data as a Json object literal from a .js file. This is done by a <script> tag in index.html, prior to the loading of the webpack bundles, which loads the configuration typically as a file from a known location, where the src of the <script> tag is deemed not part of the build.
3. Whilst this would typically be a location on the same server such as the root directory where index.html is located, it does not have to be, and could equally well be loaded from another server over http. The key point is that the precise src for the script tag is a contract between index.html and any deployment/configuration management software. For example, the configuration file might be dynamically created by Ansible or similar, or the configuration might not be a file at all, and could be dynamically created server side via a web service. These possibilities are all extensions to the basic pattern and depend on the particular web servers and deployment techniques in play.
4. When running in development mode using ng serve, the bundles are created in memory and no files exist. Therefore this mechanism will not work as the <script> tag will not load anything. We therefore provide a means of having default configuration in the code which will be overridden by the above configuration file if present. If the configuration file is not present (ng serve in dev mode) you will get a 404 for the script tag on the console, which can be ignored.
5. When running in development mode using files (e.g. via lite-server using  ng build –watch and running lite-server from the dist subdirectory), a config file can be used in the normal way to override the default config if desired.
6. The default configuration object is exported as a constant from the appropriate environment file, e.g. environment.ts. Whilst there could be default settings in environment.prod.ts, the default is typically set to null in this case so that a configuration file is always used.
7. The structure of the configuration data is typed via an AppConfig interface which is used everywhere the data is loaded or referenced. In simple cases the configuration data may be just properties of the root AppConfig object. However in more complex cases the object graph could be extensive.
8. The configuration file loads the configuration object into a global variable which is then read by the AppConfigService, and if present overrides the default configuration. Object.freeze() is used (along with readonly properties on the AppConfig interface) to make the configuration data immutable. Whilst in theory it may be possible to inject the resulting configuration as a constant using a value provider, when I tried this (with the latest Angular 4) I hit a variety of intermittent compile/build errors citing ERROR in Error encountered resolving symbol values statically. In the end I went with an injected configuration service, which consuming classes set up as a getter to allow convenient access.
9. The AppConfigService loads the global configuration variable via a casted reference to the window object. I tried to get this to work via a declare to reference it as an external object but again I hit compile errors when doing so.

Example Code Listings

index.html

<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <title>Places Admin</title>

<base href=”/”>

<meta name=”viewport” content=”width=device-width, initial-scale=1″>
<link rel=”icon” type=”image/x-icon” href=”favicon.ico”>

<script type=”text/javascript” src=”appConfig.js”></script>

</head>
<body>
<app-root>Loading…</app-root>
</body>
</html>

appConfig.js – external configuration file.

// Application Configuration
var salientSoft_appConfig = {
  appTitle: "The Places Guide",
  apiBase: "http://localhost:5984/places-guide/",
  messageTimeout: number = 3000
};

environment.ts

// The file contents for the current environment will overwrite these during build.
// The build system defaults to the dev environment which uses `environment.ts`, but if you do
// `ng build --env=prod` then `environment.prod.ts` will be used instead.
// The list of which env maps to which file can be found in `.angular-cli.json`.

import {AppConfig} from ‘../config/app-config’;

export const environment = {
production: false,
};

export const defaultAppConfig: AppConfig = {
appTitle: ‘The Places Guide’,
apiBase: ‘http://localhost:5984/places-guide/’,
messageTimeout: 3000
};

environment.prod.ts

import {AppConfig} from '../config/app-config';

export const environment = {
production: true
};

export const defaultAppConfig: AppConfig = null;

appConfig.ts – config file interface

/* Root application configuration object
   This encapsulates the global config json properties.
   These must match what is in the actual config file, normally /appConfig.js.
 */
export interface AppConfig {
    readonly appTitle: string;
    readonly apiBase: string;
    readonly messageTimeout: number;
}

app-config.service.ts

import {Injectable} from '@angular/core';
import {AppConfig} from './app-config';
import {defaultAppConfig} from '../environments/environment';

@Injectable()
export class AppConfigService {
private _appConfig: AppConfig;
buildConfig(): AppConfig {
const appConfig: AppConfig = (<any>window).salientSoft_appConfig || defaultAppConfig;
return Object.freeze(appConfig);
}
constructor() {
this._appConfig = this.buildConfig();
}
get(): AppConfig {
return this._appConfig;
}
}

app.component.ts – example configuration consumer

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements OnInit {

constructor(
private appConfigService: AppConfigService
) {}

public get appConfig(): AppConfig {return this.appConfigService.get(); }

ngOnInit(): void {
document.title = this.appConfig.appTitle;
}

No Comments »

I was using a button component to encapsulate the primeNG one, to allow it to responsively change to an icon only button at smaller screen widths. Whilst in theory I could have dynamically modified the internal primeNG button CSS, this was complex and I did not want  to become tightly coupled to it. My button component therefore simply selected one of 2 buttons via a media query, setting the unwanted one to display:none.

I wanted any classes added to the top level ss-button to be set on the underlying primeNG buttons. One use of these buttons was in a home brewed tab component, and  I was dynamically changing the button colour via ui-button-primary, ui-button-secondary so that the active tab had a ‘primary’ coloured button and the inactive ones were ‘secondary’ which caused them to become uncoloured ghost buttons – ideal for my requirement.

During refactoring to replace the ‘full size only’ primeNG buttons with the resizing ss-buttons I introduced a bug and the colour change failed to work. The initial (incorrect) refactored code was as follows:-

ss-tab-toolbar.component.html

<ng-container *ngFor="let tab of tabs">
  <app-ss-button [label]="tab.label" [icon]="tab.icon" (click)="setActiveTab(tab)"
          [ngClass]="{'ui-button-primary': isActiveTab(tab), 'ui-button-secondary': ! isActiveTab(tab)}"></app-ss-button>
</ng-container>

ss-button.component.html

<button pButton type="button" [title]="label" [label]="label" [icon]="icon" class="ss-button icon-text"
        [ngClass]="class" ></button>
<button pButton type="button" [title]="label" [icon]="icon" class="ss-button icon-only"
        [ngClass]="class" ></button>

ss-button.component.ts

@Component({
  selector: 'app-ss-button',
  templateUrl: './ss-button.component.html',
  styleUrls: ['./ss-button.component.scss']
})
export class SSTabButtonComponent  {

  @Input() label: string;
  @Input() icon: string;
  @Input() class: string;

  constructor() { }
}

The issue was that I was using [ngClass] dynamically to update the classes on the <app-ss-button> in ss-tab-toolbar.component. html. This used to work for the PrimeNG buttons, but now would have no effect as the classes need to be changed on the child buttons not the encapsulating parent. A simple change of [ngClass] to [class] fixed the problem, as the parent style change then updated the property on the parent component which was then picked up by the children correctly.

modified ss-tab-toolbar.component.html

<ng-container *ngFor="let tab of tabs">
  <app-ss-button [label]="tab.label" [icon]="tab.icon" (click)="setActiveTab(tab)"
          [class]="{'ui-button-primary': isActiveTab(tab), 'ui-button-secondary': ! isActiveTab(tab)}"></app-ss-button>
</ng-container>

Happily the dynamic nature of angular meant that this worked perfectly for tab changes – the change on the parent class was propagated correctly to the child and the button colours changed correctly.

I was wondering initially whether I would need to involve observables to make this work but this was not the case – this kind of dynamic propagation pattern is worth remembering in future.

No Comments »

A common pattern used in service layers is to make calls to an underlying repository or API, and then map the results to domain layer objects via mappers/convertors. Often, it may be necessary to make multiple repository calls and then combine them in the mapping phase to create the resulting domain object graph which is then returned. With traditional synchronous calls, e.g. to an underlying JPA repository, this is a straightforward exercise.

However, Angular 2 by default makes HTTP api call results available asynchronously as Observables, which poses an immediate issue with how to combine the results. I certainly did not want to embed Observables as properties within my domain objects, as I wanted the domain objects as POTOs (Plain Old Typescript Objects) and did not want to couple them/pollute them with Observables.

Handling the above pattern is in fact straightforward, but does involve a paradigm shift compared with imperative OO style programming as you need to get your head around reactive programming, in this case ReactiveX/RxJS which Angular uses.

• In this case we are using RxJs Observables for which the api is documented here.
• The available operators for use with Observables are documented here.
• ReactiveX/RxJs makes extensive use of Marble diagrams an example of which may be found here.
• Another useful introduction site to RxJS may be found here.

Note that it is possible to convert the observables to promises and use promise chaining to achieve similar results. However, I decided to stick with observables as the majority of comments online such as this post indicate that observables can do all that promises can, and more, and they are the default/chosen direction for Angular 2. It felt counter intuitive to have to convert the observables to promises all the time when there was no real need – whilst  and to do so appeared to go against the chosen way forward for Angular 2.

My first prototype needed to combine 2 API calls, and for this I used the combineLatest instance method. (This is called on one Observable and allows one or more other observables to be combined with it. There is also a static method available on the Observable class.) I found this solution in this StackOverflow post. These methods do do the following :-

1. Combine 2 or more observables and emits a single output observable
2. Before the output observable emits an item, all of the input observables must have emitted at least one item
3. Once all the observables have emitted something, the output emits an output item.
4. It continues to emit items whenever any of the input observables emit another item.
5. Note that in our case, multiple emits for an observable do not occur. Whilst we are using observables, each one will only emit a single output item in our case, when the HTTP call completes.
6. Note that per the example code below, I use lambdas (=> operator) routinely. The lambda used on the return of combineLatest will be called when the output observable emits an item (i.e. when both the HTTP calls have completed). The other lambdas are just used for standard synchronous filter/map/reduce operations on the arrays – these are standard in Javascript and hence Typescript, so they are not asynchronous/using observables.

For the requirement of my original pattern, i.e. make a number of repository calls, then map them all to a domain object graph, the above approach works fine. Note that there are a number of other operators on observables which are quite nuanced and this example just scratches the surface of Reactive programming, but in my experience the above is a very common pattern. Some of the other operators/methods distinguish between emits on an observable and the observable actually closing. As in the above case we just get one emit from each, we don’t need to get into that issue.

An outline example from my prototype code follows (imports and domain objects omitted for clarity). Note that it is just a prototype and a number of issues have not been properly addressed yet (such as externalisation of configuration data such as API urls):-

places-service.ts

@Injectable()
export class PlacesService {

  static apiBase: string = 'http://localhost:5984/places-guide/';
  static apiGetByLocationName: string = `${PlacesService.apiBase}_design/places/_view/placesByLocationName?include_docs=true`;
  static apiGetFeatures: string = `${PlacesService.apiBase}_design/places/_view/featuresByOrdinal?include_docs=true`;

  constructor(private http: Http, private featureMapper: FeatureMapper, private placeMapper: PlaceMapper) {}

  fetch(): Observable<Place[]> {
    return  this.http.get(PlacesService.apiGetByLocationName)

       //The lambda here is called when the output observable emits an item (which only happens once when both HTTP calls complete).
      .combineLatest(this.http.get(PlacesService.apiGetFeatures), (placesRows, featuresRows) => {
        let features: Feature[] = this.featureMapper.mapAll(featuresRows.json().rows);
        let places: Place[] = this.placeMapper.mapAll(placesRows.json().rows, features, PlacesService.apiBase);
        return places;
      });
  }
}

place-mapper.ts

@Injectable()
export class PlaceMapper {

  constructor(private placeFeaturesMapper: PlaceFeaturesMapper) {};

  public map(row: any, placeFeatures: PlaceFeatures, apiBase: string): Place {
    let place: Place = Place.create(
      row.id,
      row.doc.name,
      row.doc.strapline,
      row.doc.description,
      Address.create(
        row.doc.address.address1,
        row.doc.address.locality,
        row.doc.address.postTown,
        row.doc.address.postCode),
      row.doc.lat,
      row.doc.long,
      row.doc.website,
      row.doc.phone,
      row.doc.email,
      placeFeatures,
      apiBase + row.doc._id + "/thumbnail.jpg",
      apiBase + row.doc._id + "/detail.jpg"
    );
    return place;
  }

  public mapAll(rows: any[], features: Feature[], apiBase: string){
    let placesPlaceFeaturesMap: {[key: string]: PlaceFeatures } = this.createPlacesPlaceFeaturesMap(rows, features);
    return rows

      //this is standard array filtering and mapping with lambdas
      .filter(row => row.doc.type == 'place')
      .map(row => this.map(row, placesPlaceFeaturesMap[row.doc.placeFeaturesId], apiBase));
  }

  createPlacesPlaceFeaturesMap(rows: any[], features: Feature[]): {[key: string]: PlaceFeatures } {
    let placesPlaceFeaturesMap: {[key: string]: PlaceFeatures } =
      rows.filter(row => row.doc.type == 'placeFeatures')

        //This is a standard array lambda. Reduce is used as we are populating a single return object.

        .reduce((map, row) => {
          map[row.doc._id] = this.placeFeaturesMapper.map(row, features);
          return map;

        //Note that the {} is the seed/initial value for the reduce, where we initialise the empty output object
        }, {}

      );
    return placesPlaceFeaturesMap;
  }
}

place-features-mapper.ts

 
@Injectable()
export cl
ass PlaceFeaturesMapper {
  public map(row: any, features: Feature[]): PlaceFeatures {
    let list: PlaceFeature[] = this.buildList(row.doc._id, row.doc.placeFeatures, features );
    let map: {[key: string]: PlaceFeature} = this.buildMap(list);
    return PlaceFeatures.create(row.doc._id, list, map, features);
  }
  buildList(placeFeaturesId: string,
            rawPlaceFeatures: {[key: string]: {rating: number} },
            features: Feature[]): PlaceFeature[] {
    let placeFeatures: PlaceFeature[] = features
      .filter(feature => rawPlaceFeatures[feature.id])
      .map(feature => PlaceFeature.create(
          placeFeaturesId,
          feature.id,
          feature.ordinal,
          feature.name,
          feature.description,
          feature.searchable,
          feature.rateable,
          rawPlaceFeatures[feature.id].rating)
      );
  return placeFeatures;
  }
  buildMap(placeFeatures: PlaceFeature[]): {[key: string]: PlaceFeature} {
    let placeFeaturesMap: {[key: string]: PlaceFeature} =
      placeFeatures.reduce((map, placeFeature) => {
        map[placeFeature.featureId] = placeFeature;
        return map;
      }, {});
    return placeFeaturesMap;
  }
}
 
feature-mapper.ts

@Injectable()
export class FeatureMapper extends AbstractMapper<any, Feature> {

  public map(row: any): Feature {
    let feature: Feature = Feature.create(
      row.id,
      row.doc.ordinal,
      row.doc.name,
      row.doc.description,
      row.doc.searchable,
      row.doc.rateable);
    return feature;
  }
}

 
abstract-mapper.ts

export abstract class AbstractMapper<R,T> {
  public abstract map(row: R): T;

  public mapAll(rows: R[]): T[] {
    return rows.map(row => { return this.map(row);});
  }
}

 
									
					

						No Comments »					
					
				

A new Ionic 2 application should be created via ionic-cli as follows:-

ionic start my-new-app tabs –v2

Note that the v2 switch is mandatory, as without it (and running ionic 2.2.1) I got a different folder structure which did not put the application code under a top level src/ directory – whilst this tutorial does not mention the switch, it is mentioned here.

Note also that the tabs keyword is an app template which creates a tabbed app. There are other choices as noted here .

The super starter template is noteworthy as it has simple examples of master/detail lists, searching, and simple forms. I tried this and had some issues getting it working but there is a fixed version which worked. I have documented this here.

Note also that this post here mentions using an earlier version of node (4.x) to avoid a number of issues. I have not tried that, as the current node version I have installed as I type is v7.5.0, which makes 4.x a pretty old version.

I may try the older one though, to see if the issues I hit with the menu toggle on the Nav bar menu might be solved. The issue I have hit is that the menu icon on the nav bar intermittently does not open the side menu. Typically clicking the same tab icon again or visiting another tab makes it work, such that it alternately fails and works. No solution has yet been found for this and I could not find any reference to it online.

Note that the default generated folder structure for —   v2 creates an app directory under /src, which is used for core app configuration stuff. I did attempt (mistakenly I now feel) putting the component and service layers under /src/app, but have now reverted that. Whilst this worked, when I then tried to move (with a webstorm refactor) /src/pages/ to /src/app/pages/ I hit numerous issues with  template errors/ html files not found when running ionic serve. I checked all the import and related configuration, and whilst some was incorrect, I eventually went through and corrected every .ts file individually and still had issues. This appears to be an issue – moving the /src/pages/ directory (for an app with the tabs template, as per the above ionic command) appears to break some hidden configuration that I could not find.

No Comments »

I was looking into this in order to find the best type for an arbitrary stream of Json.

This comment post here has an interesting discussion on this, and concludes that any is the most flexible, and there aren’t strong reasons for using the Object or {} (which are similar, as {} extends Object).

This post describes how to use TypeScript interfaces to describe the Json.

http://json2ts.com is a site that automatically creates the interfaces from the json for you, however in my case it did nothing when I gave it a returned CouchDB Json stream.

This stackoverflow post also discusses the issue and mentions json2ts.com – the poster evidently had more luck with it than I did.

No Comments »

Providers need to be declared as they ‘provide’ the objects to be injected – in many cases this will be a singleton reused whenever injected (much like a normal Spring bean in Java).

To be visible everywhere in the entire application, they should be declared in the Providers list in the root @NgModule  (e.g. app.module.ts).

However if not used globally, they can be for example registered in a component whereupon they will be visible to that component and its children only.

This angular doc here discusses dependency injection and where to register providers.

This angular doc here is the NgModule faq and also discusses the issue. It points out that registering the providers in the root AppModule (@NgModule as above) is the normal use case, and other cases are rare. In particular it makes the following points:-

Should I add application-wide providers to the root AppModule or the root AppComponent?

Register application-wide providers in the root AppModule, not in the AppComponent.

Lazy-loaded modules and their components can inject AppModule services; they can’t inject AppComponent services.

Register a service in AppComponent providers only if the service must be hidden from components outside the AppComponent tree. This is a rare use case.

More generally, prefer registering providers in modules to registering in components.

Discussion

Angular registers all startup module providers with the application root injector. The services created from root injector providers are available to the entire application. They are application-scoped.

Certain services (such as the Router) only work when registered in the application root injector.

By contrast, Angular registers AppComponent providers with the AppComponent‘s own injector. AppComponent services are available only to that component and its component tree. They are component-scoped.

The AppComponent‘s injector is a child of the root injector, one down in the injector hierarchy. For applications that don’t use the router, that’s almost the entire application. But for routed applications, "almost" isn’t good enough.

AppComponent services don’t exist at the root level where routing operates. Lazy-loaded modules can’t reach them. In the NgModule page sample applications, if you had registered UserService in the AppComponent, the HeroComponent couldn’t inject it. The application would fail the moment a user navigated to "Heroes".

Should I add other providers to a module or a component?

In general, prefer registering feature-specific providers in modules (@NgModule.providers) to registering in components (@Component.providers).

Register a provider with a component when you must limit the scope of a service instance to that component and its component tree. Apply the same reasoning to registering a provider with a directive.

For example, a hero editing component that needs a private copy of a caching hero service should register the HeroService with the HeroEditorComponent. Then each new instance of the HeroEditorComponent gets its own cached service instance. The changes that editor makes to heroes in its service don’t touch the hero instances elsewhere in the application.

Always register application-wide services with the root AppModule, not the root AppComponent.

No Comments »