feat!: template-level app config overrides

[jfmcquade]

PR Checklist

• PR title descriptive (can be used in release notes)

Description

• Enables authors to override app config values by setting them in a template's parameter list.
  • These overrides will apply as long as the template is the current top-level template (either navigated to directly or launched as fullscreen pop-up).
  • On navigating away from the template, the values are set to the deployment defaults, accounting for any active skin overrides (and any overrides set by the new top-level template)
  • The immediate use case is for setting custom header and footer for specific templates.
• The header and footer app config properties (e.g. APP_FOOTER_DEFAULTS.templateName) are not restructured or renamed by this PR, nor are the new properties exposed that will be required for full header/footer customisation (e.g. for passing in a template to be displayed in the header, as we do for the footer).
  • Renaming the app config properties whilst retaining support for the legacy property names proved difficult, so I'm planning on making those changes in a separate follow-up PR. That PR will likely involve some breaking changes for deployment configs.

Breaking changes

There is an update to the way template parameter lists are parsed that has the potential for breaking changes, although none are expected. Previously, when a template parameter list was parsed from its string representation into a JSON object, only minimal further parsing was done on the values of any parameters. Specifically, the values of top-level parameters, e.g. the string "landscape" in my_param: true; would be checked to see if they were a string representation of a boolean value ("true" or "false"), and parsed to the corresponding value if so. Nested parameters, e.g. "my.nested.param = false" would be parsed into objects, but, inconsistently, the values themselves would receive no further parsing (i.e., the parsed parameter list would be { my: { nested: { param: "false" } } }.

As of this PR, the parser for template parameter lists attempts to interpret string values as native data types, such as numeric, boolean, null, or undefined string representations. I believe this is expected behaviour.

Comparing the parsed sheets for the debug deployment, the changes are minimal and only apply to the sheets introduced for this PR (as the latest content changes are in this open PR, I checked out the content/1.3.0 branch of the content repo and ran yarn workflow sync_sheets --skip-download to see the relevant diffs from parsing on this feature branch).

Git Issues

Closes #

Screenshots/Videos

feature_app_layout

feat_app_layout_header_compact

feat_app_layout_footer

feat_custom_footer

Demo with default skin active:

Default.skin.mov

Demo with debug skin active:

Debug.skin.mov

[jfmcquade]

dynamically updating the template name (for example, when changing the name of the template to display in the footer) would hitherto not trigger the component to display the content relating to the newly referenced template

[chrismclarke]

nit(blocking): I'm pretty sure this fires on init as well, meaning every template gets rendered and immediately re-rendered (looking at console logs on debug site appears to be the case). Will need to rethink how best to manage

[jfmcquade]

Good spot. I've implemented a signla based approach in f31e5d3. I would have liked to have defined template as a computed signal that evaluates when templatename updates, however I was a bit confused by some of the logic in renderTemplate() and forceRerender(), and decided it would be best not spend time trying to unpick this as part of this PR necessarily, so I've tried to leave that untouched as much as possible.

[chrismclarke]

Yeah at this point I think probably best to leave loading the template as-is. I noticed that we were still getting a double render from the effect and ngOnInit, so I removed the onInit code with e0679c8 and also did some minor tidying to make more explicit that signal value passed to the render function (could see you had included a manual workaround to call the signal value in the effect anyways).

[esmeetewinkel]

(I've not read the full thread, so I might be missing something, but)

When testing on the preview link I'm seeing a footer (with no content) on the template feat_app_layout_header_compact

[jfmcquade]

When testing on the preview link I'm seeing a footer (with no content) on the template feat_app_layout_header_compact

Thanks @esmeetewinkel, you're right to flag this as an issue. This was present on the PR preview but not when running locally because the debug content hadn't been updated to reflect the minor change to the sheet parser (which now parses nested boolean values within a template-level parameter_list), so the version on the web preview link was trying to set the footer to display a template named "false" rather than interpreting the value as false and hiding the footer.

I have now updated the debug content repo with the latest changes (see IDEMSInternational/app-debug-content#120), so the functionality on the latest web preview should work as expected (I triggered the web preview action to re-run by removing and adding the test - preview flag).

The template on the web preview link does appear to be working now: https://plh-teens-app1--pr2531-feat-template-level-5141d3ic.web.app/template/feat_app_layout_header_compact
I think I had to "Empty cache and hard reload" to see the changes (or open the link in an incognito window to circumvent any caching).

[esmeetewinkel]

Functional test passed