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:

• config

• flow

• layout

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.

Property	Strategy	Description
initial_screen	TP ●────x╭┈┈┈┈┈┈o ITEM o┈┈┈╯	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 ●──────╮ ITEM o┈┈x ╰─────●	TP overwrites ITEM if it exists on TP. On TP level we can define or overwrite currency for multiple items.
date_format	TP ●──────╮ ITEM o┈┈x ╰─────●	TP overwrites ITEM if it exists on TP.
default_values	TP ●──────╮ ITEM o┈┈┈┈╰─────●	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	TP ●─────╭┈┈┈┈┈┈o ITEM o┈┈┈╯	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 ●──────╮ ITEM o┈┈┈┈╰─────●	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 ●──────╮ ITEM o┈┈x ╰─────●	TP overwrites ITEM if it exists.
- field_definition	TP ●──────╮ ITEM o┈┈┈┈╰─────●	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 ●──────╮ ITEM o┈┈┈┈╰─────●	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 ●──────╮ ITEM o┈┈┈┈╰─────●	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.

TP     ●─────╭┈┈┈┈┈┈o
ITEM     o┈┈┈╯

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).

TP     ●─────╭┈┈┈┈┈┈o
ITEM     o┈┈┈╯