Topper Tree

[umbobabo]

StoryTelling is exploring the idea to build more features on toppers e.g. Clip on topper.

There are discussion around the idea of having a Topper Tree.

Advantages of a Topper Tree

A Topper tree that will follow the same standard of the Body Tree may bring some advantages:

1. Content Pipeline may use the same recursive engine to render the Body and the Topper
2. It should be easy to extend topper functionality with components that have been already developed for the Body: Clips, CCCs, Flourish (Although topper already exist), Imageset and potential future components like Audio or Slideshow or Photogallery
3. It will reduce the work for all the Dynamic StoryTelling teams: We will not need to design the model for every component or new feature because they are already implemented in the Content Tree for usage in the Body Tree
4. Similarly to the Body Tree, we could potentially generated a Topper HTML that external consumers could use, if they desire to do so

Disadvantages of a Topper Tree

I can't think of any personally.
Given the already existing Content Tree and cp-cp, the implementation for StoryTelling shouldn't be too complicated.
By C&M perspective, when we will publish the Body Tree, we could equally publish a Topper Tree. Spark perhaps would be the most complex bit to integrate.

What may a Topper Tree look like?

A Topper node would with a lot of supported features would roughly look like...

// Some of these don't yet exist
type MainAsset =
  | Flourish
  | Clip
  | YouTube
  | ImageSet
  | Audio
  | SlideShow
  | PhotoGallery
  | CustomCodeComponent;

interface Topper extends Parent {
  type: "topper";
  // Keep these as strings (example only)
  headline: string;
  backgroundColour: string;
  backgroundBox: string;
  textShadow: string;
  followButtonVariant: string;
  // No children is topper with no images and nothing else
  children?: [MainAsset];
}

The limit of this approach is likely related to the children. You won't be able to move children around if you want to obtain a different mark-up. However, this could be easily achievable creating sub-components if needed.
For instance, let say you are building a Topper where you have an Audio on the left and a Video on the right. You will create a MainAsset that is the wrapper for you composition and then add Audio and Video as children of that composition.

**How this may affect the Content Pipeline and the Content Tree **
The Frontend should be reasonably simple to change.

1. The ImageSet here will become the children
2. CP will have to fetch the Topper Tree like it's doing for the Body Tree and render it recursively like we are doing for the Body or even CCC component or RichText
3. The Content Tree will need to accept a Topper as root, similarly to the Body node

What if we don't do this?
We will build toppers in the usual way. That involves the 3 DS teams to getting together to define a model for each implementation, although the model or a similar one may exist already for the body.
The model will be then integrate as new fields in the topper, potentially evolving overtime in a very big and hard to control model that may not be aligned with the one used in the Body.

How would this affect existing data
We will need to think about portability of old data.
Some fields like leadImages or leadflourish, may potentially not be needed anymore because they will be model inside the supported ImageSet model and Flourish model.

Related to #73 and #84