# 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`](#config) * [`flow`](#flow) * [`layout`](#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](#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](#flow). We want to keep existing TP layouts and define custom ones in items (if needed). ``` TP ●─────╭┈┈┈┈┈┈o ITEM o┈┈┈╯ ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.kasko.io/kasko-frontend-documentation/guides/manifest-merging-strategy.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.