Expose ChatChannelInfoView to ViewFactory

[sashkopotapov]

What are you trying to achieve?

I want to set up a custom channel information view.

If possible, how can you achieve this currently?

I need to implement a custom channel header instead of DefaultChatChannelHeader and a custom header view modifier instead of DefaultChannelHeaderModifier.

What would be the better way?

The ideal way would be to have this function in ViewFactory's protocol.

associatedtype ChatInfoView: ChatChannelInfoView
    /// Creates the channel information view.
    /// - Parameter channel: the displayed channel.
    /// - shownFromMessageList: indicated the source of presentation.
    func makeChatChannelInfoView(
        for channel: ChatChannel,
        shownFromMessageList: Bool
    ) -> ChatInfoView

Also we can have a default implementation of it using the existing ChatChannelInfoView in ViewFactory's extension.

public func makeChatChannelInfoView(
        for channel: ChatChannel,
        shownFromMessageList: Bool
    ) -> some ChatChannelInfoView {
        DefaultChatChannelInfoView(
            channel: channel,
            shownFromMessageList: shownFromMessageList
        )
    }

This way it would be much easier to provide a custom chat information view by re-implementing only func makeChatChannelInfoView where we provide a custom instance, instead of implementing the whole custom header.

GetStream Environment

GetStream Chat version: 4.61.0
GetStream Chat frameworks: StreamChat, StreamChatSwiftUI
iOS version: 17.5
Swift version: 6.0
Xcode version: 16.0
Device: -

Additional context

I love the default implementation of chat, it have everything you need already, and it is very convinient to customize. Exposing the chat information view would be even better.

[sashkopotapov]

Hey @martinmitrevski, please write feedback on whether this is something you are open to doing, and I would happily create a PR to implement this issue.

[martinmitrevski]

Hi @sashkopotapov, thanks for suggesting this.

We have already discussed this internally a while ago, and we decided against it. Among the reasons is SDK parity - some of our SDKs don't have this component yet, so exposing it as a separate slot would cause inconsistency with the other platforms. Therefore, we provide it as is in the default header at the moment.

In the future, this might be revisited, but for now we don't plan on exposing this.

Hope that helps,
Martin

[sashkopotapov]

@martinmitrevski it makes sense, Martin. Thanks for clarifying it for me.