Curated front page

curated-front-page-data.js

// Here is the proposed data structure for the new home page, which consists entirely of these modules.
// Here is a wip doc for the modules: https://docs.google.com/document/d/1eA8CZmEVfwge3oNBOyD1YCiK1UIz2HXLbnBmdRzPYps/edit#
// A single blog would have an array of these modules
// HELP WANTED: help us find a freakin name for these CurationBlocks that make sense and doesn't conflict with anything
// we have currently.

type CurationBlock = {
  id: CurationBlockId, // We store an id for each one so when you edit it, we can save based on id and not index
  layout: string, // enum, each layout has its own name
  autofill?: { // If this is not undefined, the module will autofill and ignore the cards array (for now)
    blogId? BlogId,
    tagCanonical?: string,
    categoryId?: CategoryId,
    storyTypeId?: StoryTypeId // Based on what is set here, we can figure out what stream to pull from
    // For now, we only fetch 'latest' posts from the various fields, in the future we might need another algorithm
  },
  cards: [{ // Should throw error if the number of items doesn't match the slots in the layout
            // Should also throw error if the autofill property is filled and the array contains items
    postId: PostId // This is an object to future proof it: we might need title / picture etc overrides later
  }],
  header?: {
    title: string, // Even if we use a logo, it's needed for alt?
    useLogo?: boolean, // Use the logo of the blog / storyType etc. if it exists, otherwise fall  back to the title
    description?: string,
    customImage?: SimpleImage,
    links?: Array<{
      url: string,
      text: string
    }>
  },
  updatedBy: UserId,
  updatedAt: string
}

/////////////////////////

// Variant Method of Typing the modules:
// We could tie the data structure more closely to the type of the various modules themselves. So from type string
// of a module, the type of the header could be derived.
// We opted not to do this, since we will have quite a number of layouts, and it would mean a lot of boilerplate in
// scala, the previous method also makes iterating on the data a bit easier. Let me know if you have some opinion.

type SideHeader = {
    type: 'SideHeader',
    title: string,
    useLogo?: boolean,
    description?: string,
    customImage: SimpleImage,
    links: Array<{
      url: string,
      text: string
    }>
  }

type TopHeader = {
  type: 'TopHeader',
  title: string,
  useLogo?: boolean,
  links?: Array<{
      url: string,
      text: string
  }>
}

type FourEqualWithSidebar = {
  layout: 'FourEqualWithSidebar',
  cards: Array<{ postId: PostId }>,
  header: SideHeader,
  ...
}

type Feed = {
  layout: 'Feed',
  cards: Array<{ postId: PostId }>,
  header: TopHeader
  ...
};

type CurationBlock = FourEqualWithSidebar | Feed | ...;

///////////

// Or the marriage of the two systems:

type FourEqualWithSidebar = {
  name: 'FourEqualWithSidebar',
  header: SideHeader
}

type Feed = {
  name: 'Feed',
  header: TopHeader,
  numberOfCards: number
};

type CurationBlockLayout = FourEqualWithSidebar | Feed;

type CurationBlock = {
  id: CurationBlockId,
  layout: CurationBlockLayout,
  autofill?: {
    blogId? BlogId,
    tagCanonical?: string,
    categoryId?: CategoryId,
    storyTypeId?: StoryTypeId
  },
  cards: [{
    postId: PostId
  }],
  updatedBy: UserId,
  updatedAt: string  
}

//////////////////

// Endpoints for MVP:
// - GET (blogId) => Array<CurationBlock>
// - POST (blogId, id: CurationBlockId, cards: Array<Card>) => CurationBlock

// Soon:
// - POST (blogId, id: CurationBlockId, block: CurationBlock) => CurationBlock