Skip to content

Conversation

martinmitrevski
Copy link
Contributor

🔗 Issue Link

Resolves https://linear.app/stream/issue/IOS-732/provide-message-sending-params-to-messagecomposerview.

🎯 Goal

Describe why we are making this change.

🛠 Implementation

Provide a description of the implementation.

🧪 Testing

Describe the steps how this change can be tested (or why it can't be tested).

🎨 Changes

Add relevant screenshots or videos showcasing the changes.

☑️ Checklist

  • I have signed the Stream CLA (required)
  • Changelog is updated with client-facing changes
  • New code is covered by unit tests
  • Affected documentation updated (docusaurus, tutorial, CMS (task created)

@martinmitrevski martinmitrevski requested a review from a team as a code owner March 10, 2025 20:21
@martinmitrevski martinmitrevski marked this pull request as draft March 10, 2025 20:21
@Stream-SDK-Bot
Copy link
Collaborator

Stream-SDK-Bot commented Mar 10, 2025

SDK Size

title develop branch diff status
StreamChatSwiftUI 8.16 MB 8.16 MB 0 KB 🟢

@Binding var editedMessage: ChatMessage?

private let recordingViewHeight: CGFloat = 80
private let messageSendingParameters: MessageSendingParameters
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem I see with this approach is that these parameters will be static, right? The customer set's it once, but then it can't change it dynamically. So if you set skipPush: true, then all messages will have skipPush to true right?

Other alternatives I'm thinking:

  • Making the ViewModel.sendMessage() open (This way the customer can override the function and change the parameters before calling the  super.sendMessage()
  • Make messageSendingParameters a var and not let, and/or maybe provide a closure to change the paremeters before calling the sendMessage() 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first one looks like it should be more than enough, though. Unless I'm missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

subclassing won't help - customers don't want to customize the send message method, but pass different params from the view layer. Even if we make it open (which we can for sure), they would still need to re-implement the composer view.
A different option I considered is maybe expose the whole closure and let customers handle it all by themselves, basically this part can be nil by default with this default implementation:

                   viewModel.sendMessage(
                        quotedMessage: quotedMessage,
                        editedMessage: editedMessage,
                        isSilent: messageSendingParameters.isSilent,
                        skipPush: messageSendingParameters.skipPush,
                        skipEnrichUrl: messageSendingParameters.skipEnrichUrl,
                        extraData: messageSendingParameters.extraData
                    ) {
                        quotedMessage = nil
                        editedMessage = nil
                        onMessageSent()
                    }

Copy link
Member

@nuno-vieira nuno-vieira Mar 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By subclassing, they can change the paremeters without changing the existing implementation. Example:

open class CustomComposerViewModel: MessageComposerViewModel {

    public var customShouldSkip: Bool? = false

    open override func sendMessage(
        quotedMessage: ChatMessage?,
        editedMessage: ChatMessage?,
        isSilent: Bool = false,
        skipPush: Bool = false,
        skipEnrichUrl: Bool = false,
        extraData: [String : RawJSON] = [:],
        completion: @escaping () -> Void
    ) {
        super.sendMessage(
            quotedMessage: quotedMessage,
            editedMessage: editedMessage,
            isSilent: isSilent,
            skipPush: customShouldSkip ?? skipPush,
            skipEnrichUrl: skipEnrichUrl,
            extraData: extraData,
            completion: completion
        )
    }
}

Why is this not enough?

Inside the view model, the customer also has all the data and context needed to change the parameters 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes, you are totally right! They can pass the custom VM instead. Let me change stuff.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@martinmitrevski martinmitrevski marked this pull request as ready for review March 10, 2025 23:18
@martinmitrevski martinmitrevski changed the title Expose a way to setup message sending params Make sendMessage in MessageComposerViewModel open Mar 10, 2025
Copy link
Member

@nuno-vieira nuno-vieira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! ✅

Copy link
Contributor

@laevandus laevandus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@martinmitrevski martinmitrevski enabled auto-merge (squash) March 11, 2025 15:03
Copy link

@martinmitrevski martinmitrevski merged commit dedcf2f into develop Mar 11, 2025
12 checks passed
@martinmitrevski martinmitrevski deleted the message-sending-params branch March 11, 2025 20:28
@Stream-SDK-Bot Stream-SDK-Bot mentioned this pull request Mar 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants