Archive for the 'Angular' Category

Previous Page Next Page
March 17th, 2019
8:13 pm
@angular-devkit/build-angular version causes initialisation failure with angular elements Microapp POC

Posted under Angular & PrimeNG
Tags , , ,

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 »

March 2nd, 2019
11:22 pm
Compiling a custom PrimeNG theme deployed as a static asset

Posted under Angular & PrimeNG
Tags ,

I am  using multiple themes and theme selection, using custom themes

For interest I am loading the theme css as a static asset, in index.html:-

<head>
<meta charset=”utf-8″>
<title>Microapp Fabric Prototype</title>
<base href=”/”>
<meta name=”viewport” content=”width=device-width, initial-scale=1″>
<link id=”theme-css” rel=”stylesheet” type=”text/css” href=”assets/resources/themes/salient/theme.css”>
</head>

Then I am dynamically changing the href to switch themes:-

export class ThemeSwitcher {
/*
* Select the target theme
* this may be an external theme or an internal packaged one
* If the path contains a ‘/’ the theme is assumed to be an external theme source
*/
changeTheme(theme: string) {
const themeLink: HTMLLinkElement = <HTMLLinkElement>document.getElementById(‘theme-css’);
themeLink.href = theme.indexOf(‘/’) >= 0 ? theme : ‘assets/resources/themes/’ + theme + ‘/theme.css’;
}
}

A theme SCSS under the assets folder will be automatically compiled and included inline in the package only when a specific theme is referred to in the “style” section of angular.json. When dynamically switching multiple themes as above, the themes are kept as static assets and are not inlined in the package and so are removed from the “style” section. When this is done, the theme scss files for all the themes are not compiled to css automatically when an ng build or ng serve is done. This post here details how to manually install and build the scss using node-sass. It goes into other details which I haven’t needed as I am using static assets, so only node-sass is needed. If in the actual theme directory, the following commands will install  node-sass and compile the scss for the theme and also create the source map:-

npm install node-sass

node-sass theme.scss theme.css ––source-map .

This can also be added to the scripts section of package.json to make an npm command:

“scripts”: {
“ng”: “ng”,
“start”: “ng serve”,
“build”: “ng build”,
“test”: “ng test”,
“lint”: “ng lint”,
“e2e”: “ng e2e”,
“scss”: “cd src/assets/resources/themes/legacy-blue && node-sass theme.scss theme.css ––source-map .”
},

This can be run by simply using npm run scss

Note as above that npm supports the cd command in the scripts section, both for linux and windows (as detailed here). The default directory is the root of the project, and this is consistent even if you run the npm command e.g. from a subdirectory. I did not manage to find a way to automate this via an ng build or ng serve command, so these would have to be run in conjunction with npm run scss (with the latter running first).

No Comments »

May 29th, 2018
4:56 pm
Problems upgrading angular 5 project to angular 6, and upgrading angular on a PC

Posted under Angular & PrimeNG
Tags

I had serious issues trying to upgrade an existing project, and it was not clear online what I should do.

The main persistent error was:-

./node_modules/raw-loader!./node_modules/postcss-loader/lib??embedded!./node_modules/sass-loader/lib/loader.js??ref–8-3!./src/styles.scss
Module build failed: Error: Node Sass does not yet support your current environment: Windows 64-bit with Unsupported runtime (64)
For more information on which environments are supported please see:
https://github.com/sass/node-sass/releases/tag/v4.8.3

The online information on this was not clear.

Initially I used a liberal combination of npm-update and npm-update –g on various things but still had the above error.

I reached a point of installing primeng successfully under angular 6 as detailed here.

I then tried hand editing the package.json file for the upgrade project, stealing the versions from the package.json for the primeng application. However this did not appear to help -I still had the above issues.

In the end a combination of the following resolved this:-

ng update @angular/cli

ng update @angular/cli

npm install –g node-sass@latest

npm install node-sass@latest

I think the key issue here was installing the latest node-sass. I also had some code errors to resolve in the application but I did mange to run it successfully.

No Comments »

May 23rd, 2018
7:51 pm
Installing and running the PrimeNG showcase locally under windows

Posted under Angular & PrimeNG
Tags , , ,

Update 23/5/2018

I retried this using Angular 6 and the latest primeng.

Step 2/ below was not needed, and I did not install/reinstall gulp per step 3/ (not used this time – need to check/confirm re this)

The wiki steps referred to below, here, referred to using sass to build the css, but this command did not work for me even when I installed the node.js sass per here -  the –update command came back with an error.

I then gave up using sass to compile the sass files.

Because of this issue I still had to fix the theming, so tried to copy the css files as below rather than compile the sass. This time the themes folder was under src\assets\components.

I therefore created another skeleton app, installed primeng using “npm install primeng”, and then copied the themes folder from under node_modules\primeng\resources  to src\assets\components, overwriting the themes already there.

This added the css files that were missing.

I could then run the showcase with theming fully working, either using “npm start” or “ng serve” – either worked.

I did notice that the theming borders on the treetable component did not appear to work, but apart from that all the theming including theme switching worked fine.

Original Post

It is useful to have this running locally in order to can try out occasional code hacks on the example code to try out ideas or check how things work if the docs are not clear on a point, knowing that you have started from a working example.

The steps for this basically follow the wiki steps here. Note the following additions/amendments to the steps:-

1/ I cloned the repository from here. Having cloned I then listed and disconnected from the remote repositories, as the clones were just for local use:-

git remote –v

git remote rm origin

git remote –v

2/ Dependencies as follows were added to package.json as per instructions:-

  "dependencies": {
      "@angular/common": "4.0.0",
      "@angular/compiler": "4.0.0",
      "@angular/core": "4.0.0",
      "@angular/forms": "4.0.0",
      "@angular/http": "4.0.0",
      "@angular/platform-browser": "4.0.0",
      "@angular/platform-browser-dynamic": "4.0.0",
      "@angular/router": "4.0.0",
      "@angular/animations": "4.0.0",
      "core-js": "^2.4.1",
      "rxjs": "^5.2.0",
      "zone.js": "^0.8.4"
  },

Following this npm install was run to download all the dependencies

3/ In order to build using gulp as instructed (gulp build), I installed gulp first as per the instructions here:-

npm install --global gulp-cli
npm install --save-dev gulp

4/ I then ran npm start to run the showcase, which defaults to http://localhost:8080/

The showcase ran ok locally but there were some issues with the theming – the theme had a transluscent background on the menus and dropdowns for example which did not correctly occlude the text underneath. The live showcase on the PrimeNG site did not have this problem.

On investigation it appears that the theme files are under the main resources/themes directory, but are not being sass compiled from scss during the build so there are no .css files there. The gulp file for the project, gulpfile.js, does not have any entries that do sass compilation so this may be an omission/bug in the version I had downloaded.

The showcase does not use the primeng under node_modules – it defines its own primeng package such that if you try to enter npm install primeng to install the themes in the normal way as part of the npm installed package, you get an error from npm about the duplicate primeng.

My workaround was straightforward – I just copied the theme folder and all subfolders from under the node_modules\primeng\resources directory in another application folder to the projects top level resources directory (in fact I used the primeng-quickstart-webpack which I had already set up) – any other project where you have installed primeng will do. This solved the problem by providing all the css files for the themes, and the themes and theme switching then worked.

As I have no requirement to do a full working build for the showcase this is no problem.

I checked for other posts about theming issues and found a couple of StackOverflow posts about theme issues with Webpack here and here. These may prove relevant for future development.

No Comments »

June 7th, 2017
10:45 am
Using lite-server to run an angular application

Posted under Angular
Tags ,

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 »

June 6th, 2017
5:58 pm
Angular/Ionic–externalising application configuration

Posted under Angular & Ionic & TypeScript
Tags , , , ,

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 »

May 26th, 2017
12:55 pm
Dynamically updating css classes on child components from a parent property

Posted under Angular & CSS & PrimeNG
Tags , , ,

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 »

May 18th, 2017
6:30 pm
Tricks with the PrimeNG Grid CSS Component

Posted under Angular & CSS & HTML & PrimeNG
Tags ,

Update 19/5/2017

I noticed that my original attempt below, whilst causing the text div to flow under the image div at smaller screen sizes, did not cause the text div to be full width when it was sitting underneath. To do this properly I needed to use a combination of 2 specific non-default (i.e. not ui-g-*) responsive style classes on the text div, in this case ui-md-9 and ui-sm-12. This causes the following:-

  1. At the u-md-* screen size boundary, and higher, the ui-md-9 kicks in and the image and text are on the same line.
  2. Below the ui-md-9 boundary, the ui-sm-12 kicks in and allows the text div to be full width. Without this, it would sit underneath but the default ui-g-9 would still be in effect so it would not switch to full width.

The modified code fragment for the item-text div is as follows:-

<div class="ui-g-9 ui-sm-12 ui-md-9 item-text">

Original Post

I did this quite by accident, due to adding an unwanted “>” on the end of a ui-g-3 class for the div around the left image in a data list – it caused the class to be ignored.

The code (with the offending character and the ui-g-3 class removed) is as follows:-

<ng-template let-place pTemplate="item">
  <div class="ui-g list-item item-image">
    <div class="item-image">
      <img src={{place.thumbUrl}}>
    </div>
    <div class="ui-g-9 item-text">
      <h4>{{place.shortLocation}}</h4>
      <h3>{{place.name}}</h3>
      <p>{{place.strapline}}</p>
    </div>
  </div>
</ng-template>

The scss for the component is here (note this is from the component scss file so is encapsulated by Angular from bleeding out):-

h3 {
  font-size:1.1em;
  font-weight: normal;
  margin:.2em 0;
}
h4 {
  font-size:1em;
  font-weight: normal;
  margin: 0;
}
p {
  font-size:1em;
  margin:.2em 0;
}
.list-item {
  padding:.5em;
  border-bottom:1px solid #D5D5D5;
  display:flex;
  align-items: center;
}
.list-item .item-image {
  padding-right:1em;
}
.list-item .item-text {
  padding-left:0;
}

The happy effect of this was that the image div did not have a ui-g-* class to size it, so had a fixed size determined by the thumbnail, and was not a floating div. When I used a ui-g-3 class for it by removing the offending “>”, then the gap between the image and the text increased as the width changed, which is not something I wanted – the fixed padding there due to the bug was fine for all screen widths.

The ui-g-9 class happily floated next to it and flowed underneath as required. Different ui-g-* classes such as ui-g-6 and ui-g-8 just caused the flow to happen at a different width point.

I could probably have achieved a similar effect by using a ui-g-3 class for the image as I had intended, and then explicitly fixing the width for that div (or e.g. setting a min-width and a max-width).

I may need to do this or re-jig it if I have to cater for different thumbnail sizes, but my preferences is to scale all thumbnails to the same size as it gives a much better layout.

Whether this trick technically breaks or violates the ui-g-* grid css rules I am not sure, the documentation on them is not hugely comprehensive, but I will ponder this one in due course.

For now it works fine!

No Comments »

May 18th, 2017
5:56 pm
Vertically Centering items in a div–2017 version!

Posted under Angular & CSS & PrimeNG & Web
Tags ,

I posted about this kind of issue back in 2010 here.

Nowadays for my own project work I am happy to assume recent browsers, in particularly IE11 at least (noting that even this has been out a while now – it was released 4 years ago now so a reasonable start point).

This means that I am happy to use css Flex which makes this insanely simple compared to the old days. You just need display:flex;align-items:center in the container div and its content items will centre vertically.

I’ve just used this on a PrimeNG data list component to centre left thumbnails correctly in a list item with no issues.

Quite why we have had to suffer for so many years with arcane tricks (or risk ridicule by making it simple using tables for layout) is beyond me, but there we are.

No Comments »

May 15th, 2017
4:07 pm
Angular–using parent component references

Posted under Angular & TypeScript
Tags ,

I had a need to do this initially when implementing my own tab container component.

I wanted each tab to hold a parent reference to the container so that it could get the container’s active tab, to see if ‘it’ was the active tab.

There is significant discussion about this online. The parent can be injected directly via its class name, but this introduces tight coupling which is undesirable.

Another option discussed was the use of @Host in conjunction with injection, as per the angular docs here. In this case, the traversal of the injector  tree stops at the parent otherwise another compatible component could conceivably be injected from elsewhere.

My solution initially was to define parent and child interfaces which defined the interaction between them, as one would in Java. This decoupled them from each other. However, in Angular you cannot inject interfaces directly as they are not available at runtime. As I was already iterating the content children (the tabs) in the parent container, in the ngAfterContentInit() lifecycle hook (as this is the earliest point at which the content children are available), it was straightforward to manually assign the parent reference to each child via a method in the child interface. In this way the parent and children were decoupled – any parent supporting the container interface (used by the child) could host any children which used the child interface (used by the parent).

In the end I dumped the idea as it ended up a tad unwieldy – I only needed the child to detect if it was the active one and it was having to call a parent method to compare itself with the currently active tab to see if it was the one. This child element property was then used to ensure that only the content of the active tab was actually rendered. I finally just added a boolean active property on the child interface, and in the parent, when switching tabs, I cleared the active flag on the old active tab (if there was one) and set the active flag on the new active tab, as well as assigning a parent property for the currently active tab. Whilst this meant I was having to track the active flags correctly, I no longer had to handle parent references and parent method calls. This seemed less messy but it was a close call and either pattern in reality would be ok.

One point of note is that in Typescript, an interface can contain properties (as in fields in Java) as well as methods, so for example my interface for the child could contain active and default properties directly rather than having to additionally define isActive() and isDefault() methods.

No Comments »

Previous Page Next Page