Feat ContentPreview CustomStyle

[sookim-1]

Description

This Pull Request introduces a new customLayout property to the ContentPreview struct. The primary reason for this enhancement is to provide developers with the ability to customize the layout of the ContentPreview component. Previously, the use of ContentPreview enforced a specific format, making it challenging for users to implement their desired designs.

By allowing a customLayout option, developers can now easily override the default layout and create personalized designs that better suit their project's needs. This change aims to enhance the flexibility and usability of the ContentPreview component, ultimately improving the developer experience.

Changes Made

• Added a customLayout closure to the ContentPreview struct.
• Updated the rendering logic to use customLayout if provided; otherwise, it falls back to the default layout.
• Added a link to the website to READMe.

Example

import Foundation
import Ignite

struct Home: StaticPage {
    var title = "Home"

    func body(context: PublishingContext) -> [BlockElement] {
        let orderedAllContext = context.allContent.sorted {
            $0.date > $1.date
        }

        for item in orderedAllContext {
            ContentPreview(for: item) { content in
                Card(imageName: content.image) {
                    Text(content.metadata["description"] as? String ?? "")
                        .horizontalAlignment(.leading)
                        .font(.title5)
                        .fontWeight(.medium)
                        .foregroundStyle(.darkEmphasis)
                        .margin(.bottom, .none)
                } header: {
                    Text {
                        Link(content)
                            .role(.info)
                    }
                    .horizontalAlignment(.leading)
                } footer: {
                    let tagLinks = content.tagLinks(in: context)

                    if tagLinks.isEmpty == false {
                        Group {
                            tagLinks
                        }
                        .style("margin-top: -5px")
                    }
                }
            }
            .width(.max)
            .margin(.vertical, 50)
        }
    }
}

[twostraws]

I love this idea! However, I wonder whether it's better if we go down the SwiftUI-style approach of having a *Style protocol that folks can implement freely? It would make it more reusable if they wanted a custom layout style in several places.

So, there would be a contentPreviewStyle() modifier that expected some kind of struct that conforms to ContentPreviewStyle, which means implementing a body(content: Content) method that expects content to be received and to return a layout.

What do you think?

[sookim-1]

I agree with your idea.👍
I have considered the pros and cons.

The original closure-based approach provided flexibility for customizing layouts but had limitations:

1. Reusability: Styles defined within closures were confined to a single use case, making it harder to apply the same layout across multiple components.

2. Scalability: Using closures for layout customization could lead to code duplication when multiple previews needed the same design.

3. Maintainability: With the closure-based approach, styles cannot be easily decoupled from the main ContentPreview struct, potentially leading to tightly coupled code.
   By shifting to a protocol-based design with ContentPreviewStyle, the following benefits are gained:

By shifting to a protocol-based design with ContentPreviewStyle, the following benefits are gained:

1. Reusability: Custom layouts can now be encapsulated in a struct conforming to ContentPreviewStyle, enabling the same layout to be reused across various previews.

2. Consistency: SwiftUI-like modifiers (contentPreviewStyle) make the API more consistent and intuitive, allowing developers to define and apply styles in a uniform manner.

3. Extensibility: This approach opens up future possibilities for adding more style-related features without affecting existing implementations.

Example

import Foundation
import Ignite

struct HomeEn: StaticPage {
    var title = "sookim's T.W.L"

    func body(context: PublishingContext) -> [BlockElement] {
        Group {
            NavBar(name: "sookim's T.W.L", language: .english)

            let orderedAllContext = context.content(ofType: "en").sorted {
                $0.date > $1.date
            }

            for item in orderedAllContext {
                ContentPreview(for: item)
                .contentPreviewStyle(MyCustomContentPreviewStyle())
                .width(.max)
                .margin(.vertical, 50)
                .background(.white)
            }

            SocialFooter()
            IgniteFooter()
        }
    }
}

struct MyCustomContentPreviewStyle: ContentPreviewStyle {
    func body(content: Content, context: PublishingContext) -> BlockElement {
        Card(imageName: content.image) {
            Text(content.metadata["description"] as? String ?? "")
                .horizontalAlignment(.leading)
                .font(.title5)
                .fontWeight(.medium)
                .foregroundStyle(.darkEmphasis)
                .margin(.bottom, .none)
        } header: {
            Text(content.author ?? "fa")
            .horizontalAlignment(.leading)
        } footer: {
            let tagLinks = content.tagLinks(in: context)

            if tagLinks.isEmpty == false {
                Group {
                    tagLinks
                }
                .style("margin-top: -5px")
            }
        }
    }
}

@twostraws

[twostraws]

Apologies for taking so long to review this! This is a big improvement, and I'm going to merge it now. Thank you! 🙌