Manifest merging strategy
Introduction
As we now have ability to write manifest for touchpoints, we needed a way to merge TP manifest with ITEM manifest in a way that makes sense and do less effort of updating manifests for hundreds of items, but only apply changes in one place (TP manifest).
Before we dive into it, it would help to better understand how and why, lets imagine case where there are 3 ITEMs in one webapp and it's used by 100 different TPs. That way we can imagine why and where TP should be overwritten by and be overriding ITEM.
Strategy
There are multiple moving parts in manifest so we cannot just override one with other or do blind merging with ITEM and TP manifests.
Manifest in it's root consists of 3 main parts:
All of these we will handle differently.
Config
Lets look at config first as it's most complex in terms of how we merge it.
It also consists of multiple moving parts.
initial_screen
ITEM overwrites TP if it exists in ITEM.
On item we should be able to define start screen when TP doesn't have one.
currency_template
TP overwrites ITEM if it exists on TP.
On TP level we can define or overwrite currency for multiple items.
date_format
TP overwrites ITEM if it exists on TP.
default_values
TP merges over ITEM.
On TP level we can overwrite existing values (deep merge not shallow merge, as it could end up in unexpected bugs where previously existing value suddenly got removed).
computed_values
ITEM merges over TP.
ITEM replaces any values that are set on TP with the same field name. Rest of them are kept from TP.
requests
TP merges over ITEM.
TP should be able to overwrite front end field_definition and request transformers. We match requests by type and shallow merge field definition and transformers on them.
- version
TP overwrites ITEM if it exists.
- field_definition
TP merges over ITEM.
Field definition will get shallow merged with matching name and path. But definition contents validation etc., will get overwritten.
- transformer
TP merges over ITEM.
Transformer will get shallow merged with matching name and path. But transformer contents path, send_to_api, value etc., will get overwritten.
content_key
TP merges over ITEM.
Flow
Now lets look how flow gets merged as this is more simple than config. In a essence it's just an array screens. We want to be able to define screens on TP and on item too.
So we merge ITEM over TP here (not just basic array merge, it finds corresponding path and replaces existing, one by one). And this is how we were doing things before.
There could be some issues if we do it otherwise.
Layout
With layout it is basically the same as with flow. We want to keep existing TP layouts and define custom ones in items (if needed).
Last updated