The browser client is built using AngularJS. The AngularJS project is getting overhauled and replaced by a fully refactored framework simply called Angular. The two projects are similar in concept, but the underlying code and how we as developers build code for each is quite different. Transitioning to Angular will require significantly more code changes than a typical AngularJS update.
The final release of AngularJS will be version 1.7. It will be an LTS release with 3 years of support.
https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c
A pile of new stuff since the last update. The biggest is locale-switching support. I opted for path-based locale handling (/eg2/fr-CA/, /eg2/en-US/, etc.) since it's very convenient. I've also added support for the eg_locale cookie used by the angularjs client and the tpac. If the cookie is present, it overrides the path. Similarly, if no locale is present in the path and no cookie is provided, it will default to /en-US/. The locale need not be included in the URL if you want the server to figure it out. Most importantly, links from the angularjs app to the ang6 app will just work.
Other additions:
After much experimentation, it's clear there's no way to implement dynamic rendering (from run-time generated html strings) in production mode in an Angular-compatible way. This is intentional by the angular team. Here's a comment that summarizes the situation:
https://github.com/angular/angular-cli/issues/9306#issuecomment-378081686
Basically, JIT is "developer mode", shipping the extra compiler bits to the browser is bulky, and above all, it's a huge security risk to render dynamically generated html (more so html modified in the field by staff). And of course they're not wrong.
Brainstorming for alternate ways to allow sites to easily modify print templates under way…
One option of course are well documented stock templates with lots of knobs and switches for controlling how receipts, etc. are generated. Other options are server-generated receipts (speed concerns, offline printing?).
Continuation from yesterday's notes about dynamic rendering.
I've set up a PoC where the main app is built with –prod and –aot for optimization, and a second tiny app is built without –aot (or –prod which requires –aot). The second app contains a single DynamicComponent class exported as an Angular Element, so the main app can import it and use it for dynamic rendering.
It works well, but comes at a cost.
So we can have targeted dynamic rendering, with a quick pre-compiled main application, but it almost triples the download size. In affect, we are including 2 copies of Angular and its dependencies to accomplish this. It also adds a little bit of build-time complexity.
Here's an example of how server-hosted overrides could work:
<eg-dynamic-component
contentUrl="/test-template.html"
[contextData]="{world:'world'}"
(onComplete)="renderLocal=!$event">
</eg-dynamic-component>
<div *ngIf="renderLocal">
<b>fall through local template: hello {{world}}</b>
</div>
If eg-dynamic-content fails to fetch and render the requested URL, it reports the results via onComplete. When it fails, it sets renderLocal to true, allowing the stock template to render.
UPDATE: The above code only works when the application is compiled with the JIT compiler. After much digging, it appears dynamic complilation is not possible when using the AOT compiler. (The AOT compiler is preferred for production because it creates code that renders faster in the browser / requires less cpu at render time).
In the context of a public catalog, we could potentially build it as a separate app (we'll likely do that anyway) that can optionally use the JIT compiler for dynamic content.
Considering other options for dynamic print templates…
UPDATE2: A possible option would be to create a separate angular app with one component that knows how to render dynamic content. This app will be complied via JIT and packaged as a standalone Angular Element. It could then be imported into the main app by loading its js bundle. In theory, that would allow the main app to be compiled with AOT. Angular Elements are new, though, and it sounds like they will be much improved in Angular7.