Salient Soft

Tutorials/examples used

1. Simple tutorial here on free code camp
2. Building Progressive Web Apps by Tal Ater. This includes a source example on github.

Issues/Points Found:

1. My angular code has a number of cases where a query string is passed to a url. When caching a url or searching for one in the cache, it is important to remove all query strings and “#” fragment identifier. All my urls which are added to the cache are constants from a js/json file, and so no explicit removal is needed in the code. For searching, I use the {ignoreSearch: true} option on caches.match which strips all these on searching. Initially I appeared to have issues getting this working on all browsers, especially mobile, but in due course I established that there were other bugs at play, and in fact the above option works reliably across all browsers, including chrome and firefox on android.
2. A valid manifest .json must be declared in index.html, and this must have at least one icon of at least 144×144 in size. This is a PWA rule.
3. A promise was not being returned to the install event in free code camp example – this was due to braces being used in the install event code, but no explicit return was used to return the promise. The code did use a waitUntil in the install event, so clearly was expecting to wait for the cache additions to complete. The event waitUntil will therefore get an undefined return and not wait for the promise (i.e. the addAll to the cache) to complete. The PWAbook example above does do this correctly, and the code is very similar, but I copied and pasted code from each of the above in various examples and did not notice the missing return keyword in the free code camp example. This was subsequently remedied and all my code.
4. Service worker are always installed immediately after registration see here:
   I have not always seen this. I have often failed to see the console logs for the install event and the cache add/creation on the web site devtools console, but I suspect this is due to an existing service worker being used rather than a new one. The service worker has its own dev tools page and having just loaded a PWA web site locally on a new unused port, I noticed that the install event console logging was visible both on the dev tools for the pwa site and for the newly created service worker. All of this happened before any attempt was made to install the PWA app via the browser.
   Service workers are reused unless terminated/removed, even when the web app is updated. However you can force a new service worker on update by visiting the Application/service workers menu option on the Application page of the dev tools, and ticking update on reload. I did not prove this/try out in detail, but I did leave it on normally when developing.
   This issue may also be due to timing issues due to the bug in 1/, the promise not being returned therefore the code does not wait for all the urls to be added to the cache.
5. Service workers may be viewed via the following chrome urls:
   chrome://inspect/#service-workers
   chrome://serviceworker-internals/
6. For android, there are no dev tools available, but you can enable usb debugging. Visit the developer options under settings, and then enable usb debugging. You can then plug the phone into a windows pc via usb, and visit chrome://inspect/#devices to list the available usb devices, and connect to them, which opens a dev tools window.
7. Note that it takes up to a minute or so after the addAll is performed to the cache for it to appear as populated in the Applications tab of the chrome inspector. This was misleading at first as it looked as if it had failed/not been performed when it actually had.
8. Initially I did often see errors loading certain urls into the cache. To log this, I switched to using a loop to iterate the cache urls array, and used sequential cache.add() calls rather than cache.addAll(). This allowed logging explicitly of the ones in error (cache.addAll did not give detailed errors about the urls that had failed). Cache.addAll() is better though as it performs the adds in parallel and so is faster, so having got the pwa working I have reverted to using cache.addAll. I suspect these errors were due to code issues, in particular the above timing issues due to the missing return keyword.

Having battled through all these issues, I was able to get reliable operation, both online and offline, and both on windows and Android, with both Chrome and Firefox.

Comments Off on Progressive Web Apps – Technical Points/Issues Found

I just hit this when editing a couple of existing posts.

All the post content except the header had disappeared, and I did not seem to be able to recover it. Whilst trying, I did receive an error once about the block format, indicating there was a bug with the block layout additions in WordPress. It is possible that there is also an issue with an existing plugin/plugin version that I am using.

In the end, I discovered a reasonable workaround. When editing the post to update it, click the triple dot menu in the top RHS of the right hand pane. Then select the code editor rather than the visual editor. This revealed all the existing content but in raw code mode.

When I then clicked on the Visual editor again, all of the content came back as originally posted.

I looked for solutions/workarounds online but could not find anything concrete. Whilst this is a nuisance, I can live with the workaround for now, until I can find the time to give more effort to a proper fix/solution.

Comments Off on WordPress post content has disappeared when trying to edit existing post

In V6 or PrimeNG, you could enable drag drop reordering on the picklist and still scroll on a touch device, e.g. on a mobile phone. This was handled nicely by using a click and hold to select an item for drag drop, and a swipe to do scrolling.

In V13 this is now broken – touching on an item instantly selects it for dragging, without using the previous click and hold, so that it is not possible to scroll by swiping the source or target list any more. I have confirmed that it used to work on my old V6 microapps version which used a standard PrimeNG V6.1.3 picklist, and also have checked the current PrimeNG showcase online – the current showcase is broken in exactly the same way when trying to scroll via touch on mobile. Whilst scroll bars are present on the RHS of the list, they are very small for Mobile. I did try to enlarge the scroll bars for mobile, using some webkit specific styling, but this proved problematic as it is not fully supported for Firefox – they cannot be resized on firefox. Even when I did get it working, selecting the scroll thumbtrack for mobile proved intermittent and tricky – not a nice interaction at all.

My simple workaround for this is to disabled dragdrop for the picklist for a touch device by setting dragdrop=false (i.e. dragdrop=!touchDevice). I already have a config property in the fabric to detect a touch device, and have replicated that as a global config parameter which is visible to all the microapps. The picklist can then use this. This is actually better than it sounds – whilst you cannot reorder items within a list any more, you can move between source and target using the buttons, and drag/drop is tricky on a mobile anyway as the source and target lists appear one above the other with typically only one of them visible so dragging between them is tricky as again scrolling is involved.

For reference, changing the scrollbar styling via the webkit styles is documented here and here.

Applying the webkit styles is very picky per the posts above – spacing etc. matters – there must not be a space between the element/class name and for example ::-webkit-scrollbar or it won’t work. In the end this SCSS styling worked for me, and fortunately I was able to get it working with a classname rather than just e.g. a ul element which is the one I wanted to hit:

.p-component.p-picklist {
  .p-picklist-header {
    background: $ss-widget-header;
    color: $ss-widget-header-text;
  }

  .p-picklist-list {
    &::-webkit-scrollbar {
      width: 50px;
      height: 50px;
    }
    &::-webkit-scrollbar-thumb {
      width: 50px;
      height: 50px;
      background: #a8a8a8;
      border-radius: 4px;
    }

As above I dumped this approach anyway, as even with a very large scrollbar and thumb track, it was difficult to consistently scroll on mobile, and anyway  the source and target for drag/drop were not both in view simultaneously anyway.

Comments Off on PrimeNG V13 Picklist Component does not scroll on touch device when drag drop enabled

An old chestnut this – when upgrading from an old version on my hosted environment, my chrome based dev desktop worked fine, mainly due to my habit of hitting ctrl/f5 which clears the cache before loading.

However, on my android mobile, this needs an explicit cache clear before loading the page e.g. via the settings/history etc., which I was not in the habit of doing. Therefore when testing the new version on mobile, it failed. The new version was a production build which did not have source maps. The old version was a dev one with source maps. The console errors indicated an inability to find and load the source maps, which were not present in the latest prod deployment, but were still being requested by the cached scripts on the mobile. An explicit cache clear solved the problem. 

When I tried this again on the desktop without the cache clear, i.e. with a straight refresh, I was able to duplicate the error seen on the android chrome.

Note that the problem only applies to the fabric deployment as all the others have a timestamp (ts=) querystring parameter added to the scripts when loading, which prevents caching. I normally disable the output hashing on all microapps including the fabric for convenience, to avoid editing the app config to change the names of all the dynamically loaded scripts, even for a prod build.

Doing this on the Fabric is unnecessary as the scripts are not loaded dynamically by my code, so if I left the hashing on for the fabric, this would solve the problem, as the timestamp querystring would sort the issue for all the others.

Going forward, I intend to improve automation of the build process for hosted deployments by providing e.g. an NPM script to build all the microapps into a single zipped deployment which can be just uploaded and unzipped – at present I am having to do each one individually and copy up the dist directory. Whilst all this is only a POC application, I am doing it often enough to make this worthwhile so as not to waste time or make mistakes with it.

Doing this would also allow the possibility of using my own timestamps on all the filenames for every script, and dynamically modifying the config to incorporate the timestamps in the build script. This would allow caching to be left enabled for the code scripts (but not for the config), which would actually be a benefit as it would improve startup times and lessen bandwidth usage – especially relevant for mobiles. I could add a fabric config parameter to indicate whether the querystring timestamps should be added or not when loading scripts, so that the feature can still be used when needed. Perhaps I could leave this enabled for dev mode and not bother with timestamps on the actual filenames for example.

Using my own timestamps on the names would simplify and standardise the names, as I could use an identical timestamp on all scripts for every microapp done as part of a given build, to simplify naming and build automation – I would only need to pass around one single timestamp parameter which would be used for all generated script files and in the config.

Comments Off on Caching of old microapp scripts breaks new version

Unfortunately with V13 of PrimeNG and its supported chart.js versions, the axes do not get removed when switching  chart types and bleed onto the next chart. It appears that the chart must be destroyed and recreated when changing types – a refresh or reinit call are not enough, and explicit angular change detector calls don’t work either, see here.

Therefore as just having a single permanent chart and changing its properties fails as above, I’m explicitly making the chart data undefined to ensure that the *ngIf in the template destroys and recreates the chart. This works fine.

This appears to be a new bug.

Comments Off on PrimeNG V13 Chart Axes Bleedover Issue

I hit an issue where a PrimeNG panel, used in a Dataview component in grid mode, was not centering its header text after upgrading to the latest V13.

The issue was weird – the header container div was set to flex by the Panel component itself, but when I used justify-content: center to center the text in a dependent span, it remained left justified despite all my efforts to check for other style issues, force styling with !important etc.

When I checked the latest PrimeNG showcase online, I noticed that this also has the same problem. I noted that other containers/elements in the Panel such as the content container div did not use flex, so I felt happy to force the styling for the container back to block and use text-align: center instead. I did this locally in the affected microapp component rather than the overall theme, but might rethink this later and standardize if I hit the issue again.

This solved the problem and the text centered correctly.

Comments Off on PrimeNG V13 Panel Header Text Not Centering

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

… 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

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 »