Proposal: Redesign ConversationView for Composability

[ziadtamim]

Overview

This proposal to redesign the ConversationView to be more composable. Rather than using environment variables to inject child views, instead shift the responsibility to the parent view, enabling flexible composition.

Motivation

• @Environment is intended for configuration or lightweight data—not for injecting views.
• SwiftUI encourages a parent-driven API using modifiers like .sheet, .toolbar, etc., to manage optional views.
• By adopting this pattern ConversationView becomes more flexible, and separation of concerns.

Proposed Changes

• ConversationList acts as a layout container responsible for structuring the chat UI.
• Introduce .messageComposer(...) as a view modifier to optionally attach a composer input area.
• Attachment actions are passed via a @ViewBuilder, allowing inline customization with full control.

⚠️ Trade-off

1. The message composer is optional and not enforced. Client must explicitly add it when input is required.
2. The composer is no longer a hidden implementation detail. This exposes more of the view’s internal structure.

Usage Examples

With Attachment Actions

ConversationList($messages) { message in 
  // Messages, etc.
}
.messageComposer(
  placeholder: "Type your message...",
  attachmentActions: {
    Button(action: {}) {
      Label("Photo", systemImage: "photo")
    }
  }
)

Without Attachment Actions

ConversationList($messages) { message in
  // Messages, etc.
}
.messageComposer(placeholder: "Type your message...")

[peterfriese]

Thanks for your proposal, @ziadtamim!

I think users of ConversationKit shouldn't have to concern themselves with having to set up the message composer view - that should be an implementation detail they don't have to care about.

I'm also not convinced that SwiftUI doesn't use the environment (or preferences) for registering views. Toolbar is a good example.

This code snippet registers three toolbar items, one on the ScrollView, the other one on the ZStack, and the third one on a Spacer (!) that is nested inside the LazyVStack

  public var body: some View {
    ZStack(alignment: .bottom) {
      ScrollView {
        LazyVStack(spacing: 20) {
          ForEach(messages) { message in
            content(message)
              .padding(.horizontal)
          }
          Spacer()
            .frame(height: 50)
            .toolbar {
              Button(action: {}) {
                Text("Three")
              }
            }

        }
        .scrollTargetLayout()
      }
      .scrollTargetBehavior(.viewAligned)
      .scrollBounceBehavior(.always)
      .scrollDismissesKeyboard(.interactively)
      .scrollPosition(id: $scrolledID, anchor: .top)
      .toolbar {
        Button(action: {}) {
          Text("One")
        }
      }


      MessageComposerView(message: $message)
        .padding(.bottom, 10) // keep distance from keyboard
        .focused($focusedField, equals: .message)
        .onSubmitAction {
          submit()
        }
    }
    .onChange(of: messages) { oldValue, newValue in
      scrolledID = messages.last?.id
    }
    .toolbar {
      Button(action: {}) {
        Text("Two")
      }
    }
  }

The end result: a toolbar with the two items we registered.

Given that a toolbar is a UI element that will be shown on a container, the actual implementation probably makes use of SwiftUI's preference system, but I am pretty sure they inject the view either into the environment or into the preferences.

[ziadtamim]

@peterfriese The toolbar is interesting as it can be attached at various levels within the view hierarchy. My assumption around Environment and PreferenceKey aren’t designed to hold or pass views is more around SwiftUI uses opaque types where the view's body is responsible for returning the concrete view type, which enables compiler optimizations.

For that reason, using the type eraser AnyView made sense when defining the AttachementActions' environment key to hold the result builder. However, it felt like a potential code smell since type erasure can limit compiler optimizations. I was wondering if redesigning the component might help avoid the need for the type eraser.

On the other hand, I’m not entirely sure how the toolbar is designed or if the compiler somehow generate some extra wrappers to hold the result builder while preserving the required types. It’s also possible that Apple uses type erasers in those cases, treating it as technical debt to be addressed later on as the language evolves around opaque types with its current limitations.

[ziadtamim]

@peterfriese Turns out I was mistaken earlier, iOS 18+ Apple introduced an API that let us avoid AnyView and also iterate through subviews using Group(subviews:transform:).

Here’s the updated code I’ve tried out:

extension EnvironmentValues {
  @available(iOS 18.0, *)
  @Entry fileprivate var attachmentActions: SubviewsCollection?
}

extension View {
  @available(iOS 18.0, *)
  func attachmentActions<Content: View>(@ViewBuilder content: @escaping () -> Content) -> some View  {
    Group(subviews: content()) { subviews in
      environment(\.attachmentActions, subviews)
    }
  }
}

struct MessageComposerView: View {
  @Environment(\.attachmentActions) private var attachmentActions
  
  var body: some View {
    if #available(iOS 26.0, *) {
      GlassEffectContainer {
        HStack(alignment: .bottom) {
          if let attachmentActions {
            Menu { attachmentActions } label: {
              Image(systemName: "plus")
            }
            .controlSize(.large)
            .buttonBorderShape(.circle)
            .glassEffect(.regular.interactive(), in: .circle)
          }
          // ... other parts
        }
      }
    }
  }
}

``