Salient Soft

Update/Fix 24/2/2022

It appears that in the end much of this issue was down to a basic error on my part! I have previously documented here and here about the collision of object namespaces when loading multiple webpack bundles for separately deployed web components/angular elements. My solution is to perform a custom post build step to rename the root webpack objects to be unique for each webpack deployment.

This requires building to be done using npm via npm run build rather than the basic angular/cli ng build. Unfortunately I did the latter when initially rebuilding the microapps, hence the post build step did not run and I suffered the consequences I have seen previously due to namespace collisions. Once I rebuild everything correctly, all the microapps worked fine.

Original Post

I had reinstalled a PC from scratch with Windows 10, and this required rebuilding my whole dev environment from scratch. I hit some issues when I just simplistically tried the latest node via nvm install, and the latest angular (14) on projects previously run under angular 11 – builds failed and would not complete. Initially I had failed to install node-sass, so installing this helped, but I was still getting webpack errors on building.

I reverted to angular 11, but also reverted node as well. Finding a compatibility matrix for the versions was tricky but this one on stack overflow was a real help. I therefore reverted node to 12.11.1 using nvm install 12.11.1., and reverted node-sass to 5.0 due to some build errors that stated that 4.0 or 5.0 was needed.

Having done this, I was able to do a build using ng build, but this would not run using http-server, which gave the error “Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client”. My next action was to suspend/pause Kaspersky Antivirus, which helped, as it revealed a firewall port that I needed to enable. When I then immediately tried running directly using ng serve, this worked fine and I was finally able to successfully run my microapp fabric.

I then uploaded the built microapp as a test version under my zen hosting and tried running it from there. This ran fine with no errors, pointing to a local issue with my http-server. This likely needed an older version. I reverted to 0.12.2 to correspond with the current version when I last worked on the microapps, using the http-server version list here,  but this did not work.

I then checked exactly which versions of key components had been used successfully under Windows 7, and reverted to exactly those versions. These were v15.5.0 of node.js, and v0.12.3 of http-server. This worked successfully, and I was able to run compiled versions of both the fabric and the dataview microapp. Whilst I could have checked the versions used previously more carefully, this certainly highlights the potential brittleness of the environment as a whole to version changes.

I then upgraded http-server to the latest version and tried again, and everything still worked fine. Therefore, this definitely appears to point to an issue with the version of node.js alone. It also highlights issues with the version matrix I hunted down previously as above. I ended up using a later version of node which was technically incompatible in terms of the above version matrix, but which worked successfully, whereas a version mandated by the version matrix failed completely with the above error.

This whole area of versioning can certainly prove to be an unexpected and ill-documented minefield!

Comments Off on Issues when reinstalling NVM/NPM/Angular environment under new PC build

I had some issues when upgrading to windows 10 – when sleeping/waking I sometimes got a blue screen error which forced an immediate reboot. I was running bios revision F18, so elected to upgrade to the latest non-beta version which was F22 at the time.

Reflashing was fine using qflash straight from the bios having placed the new bios image on a flash drive. It was also safe as the motherboard was dual bios so wouldn’t brick itself if I accidentally had a power fail whilst flashing.

However, Windows 10 would not boot after the reflash. The reflash reset all motherboard settings to default, so after some investigation I noticed that the Peripherals, SATA mode selection was set to IDE rather than AHCI, the latter being required by Windows 10 (and also used by my Windows 7 installation previously). Changing this allowed the system to safely reboot, only needing a slight repair fix by windows which took only a few seconds. All was then well. I had also tried to set the OS type to “Win 8” rather than the default of “Other”, but this was in fact a red herring – not sure what this setting does exactly (claims to allow certain Windows 8 features but does not elaborate), so in the end I just left the setting at “Other”.

This fixed the issue. 

Comments Off on Windows 10 Boot issue after Gigabyte GA-Z77-D3H reflash to F22

I experimented with mounting a backup image from a particular backup point on a job, using the Backup software.
This worked fine, and a new drive letter was created which could be browsed directly via windows explorer.
I was not clear how to dismount the image, and the documentation said that it would only remain mounted until a reboot anyway.

In fact, after rebooting, the image remained mounted in error even if the backup disk was not available (obviously it could not be fully browsed). I managed to remove it consistently by de-assigning its drive letter in disk management, then rendering it offline in disk management, and then using device manager to delete the UIM device for the mounted image, which appeared under disk devices. This worked ok providing all the steps were done in the right order, otherwise it appeared to remain around after a reboot.

After trying again in the backup software, I found it was a simple user error – the mount screen allows selection of a drive letter, and if one is already selected you can select “None” again to remove it and dismount the image. This was not immediately obvious the first time around – I failed to notice that “None” was available in the list as it was hidden and you need to explicitly scroll to the very top of the list to see it.

Once I dismounted the image this way, it worked immediately and completely removed the image and the device even without a reboot.

Comments Off on Dismounting a Paragon Backup Image

… as above – I received the following error in relation to a PrimeNG p-dropdown used with a p-dataview:

Error: The target entry-point “primeng/dataview” has missing dependencies:
– @angular/cdk/scrolling

This issue is covered here.
I haven’t seen this before, but installing @angular/cdk resolved the build failure. This appears to be a transitive dependency issue which should have been resolved by my dependencies on PrimeNG.

Comments Off on PrimeNG 11/Angular 11 build fails due to missing @angular/cdk dependency

I was using a JSON file to hold external configuration for an agular application, using the pattern detailed previously here, and the loading mechanism detailed here.

The configuration pattern used allowed parameters to be overridden dynamically from query string parameters, so that for example you could choose an application theme in your URL.

I wanted to further extend this to allow sticky configuration parameters using localStorage, in particular to support a sticky pinnable title banner as detailed previously here. The aim was that both the query string support and the sticky localStorage support would be encapsulated in the configuration pattern and all transparently handled by the existing configuration service. The service would be enhanced with a new method call to allow persisting of a sticky parameter to localStorage and to the loaded config, for example for my sticky pinnable banner, to allow calling to persist the new pin state when the pin state was changed via the pin button. The previous pin state would then be loaded when the site was subsequently visited. Sticky parameters would override settings in the JSON file, and query string parameters would further override both of the former, and a query string parameter would also be sticky and would persist to localStorage, so for example the previous theme selected in the URL would be remembered.

One challenge was that whilst the configuration structure conformed to a Typescript interface, I needed to dynamically update configuration parameters from query string parameters or localStorage. This meant using dynamic keys e.g. based on the querystring parameters. Whilst this was initially possible by casting the config structure and using a map style lookup with config[keyVariable], it was not possible to dynamically infer the type of a configuration parameter from the interface, noting that both query string and localStorage parameters are strings. Often this is not a problem, as the default javascript behaviour will quite often cope, but therein lies a danger. In one case with a boolean, my query string/localStorage parameter was of course a string, and when written to the configuration using a dynamic key name as above, it was written as a string rather than the boolean expected in the interface. This meant that the value ‘false’ was in fact interpreted as true, due to the standard javascript truthy behaviour whereby a non empty string counts as true.

In the end, my solution was to have a subsection in the configuration, called dynamicParams, which contained all these dynamic parameters. It was therefore a requirement that all the dynamic parameters were strings and that client code reading the configuration had to be aware of that and convert as required.

One useful feature was to use Typescript intersection types for the dynamic parameters section, as detailed here. This allowed me to specify the dynamic parameter names explicitly, to allow them to be read in code directly as for example using config.dynamicParams.theme. I could also use programmatic access as above using config[keyVariable].

The section of the interface definition to do this was as follows:-

export interface AppConfig {
   appTitle: string;
   description: string;

   /* These parameters can be overridden from URL query parameters
    * and/or sticky local storage parameters
    * They must all be strings as are accessed by key programmatically */
   dynamicParams: {[key: string]: string | undefined} &
      {
         theme: string;
         pinBanner?: string;
         profileId?: string;
      };
   propertyDetail: {
      defaults: {
      photoLinkHoverText: string;
   }
   …

A particular point of note was that the intersection type using “&” was needed for this to work, rather than the union type “|”.

This solved the problem satisfactorily and all worked fine.

Comments Off on Dynamic Typing issues with Typescript/Angular 11

In angular 6 I was able to load custom static scripts, either via script tags in index.html, or dynamically, by placing the scripts in the project root (when using ng serve), or in the dist/projectname folder when running the built application. I originally used this for externalised configuration per my original post here, initially using script tags in index.html, and later using dynamic script loading via APP_INITIALIZER, which allowed dynamically named config files derived from query string parameters, and also early dynamic loading of external scripts such as for Yoti.

However, in angular 11, these use cases all gave 404 errors on the script. Posts such as this one here pointed to the need to place static files under the assets/ folder (although the post used an earlier angular version than 6, so I would expect it to work). I tried this, and both the static and dynamic use cases then worked correctly. I suspect that this is due to changes in the packaging when building and using ng serve. I retried a simple new project with a static script called from index.html, both under 6.1.7 and under 11.0.6. Under the older version, scripts in the root folder worked, but under 11.0.6, I had to place the scripts under assets (or in a subfolder of assets). This clearly demonstrated and resolved the problem.

Comments Off on 404 error when loading external config script in angular 11

Originally I used ngAfterViewInit to perform some custom DOM changes in a component (adding a default title to certain dynamically added anchor tags).

Unfortunately this resulted in weird behaviour whereby the changes did not appear in the DOM. It appeared that the DOM was being rebuilt again after the lifecycle hook had been called, as initially in debug the changes could be seen on the page, then they instantly disappeared.

Switching to using ngAfterViewChecked resolved the problem, as noted in this StackOverflow post. Whilst there are efficiency issues to consider here, it is obviously essential that the lifecycle hook used is guaranteed to be called every time the DOM is updated. Note also that the first time through flag used in the above StackOverflow post did not work – clearly the DOM was still being changed after the first call to ngAfterViewChecked, so the first time through flag was dropped. This other StackOverflow post also discusses the same solution to the problem.

Comments Off on Angular changes DOM again after calling ngAfterViewInit

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 »

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 »

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 »