feature/delete-message

[emorissettegregoire]

Allow message deletion by passing the message timestamp to the delete_message method

[matthewblack]

At this point, we should be looking at all this code as the extendable version of Stealth. Even though, we don't have to build the actual functionality we shouldn't be making code that we will have to peal back later once we get to SMS/Bandwidth.

Hopefully that makes sense!

[emorissettegregoire]

Yes absolutely, my bad. Will do! Thanks

[kladaFOX]

DIdn't get the idea, so if I want to delete message I should call smth like this:
say(nil, thread_id: 'THREAD_ID', delete_message: 'MESSAGE_TS') right?

[emorissettegregoire]

DIdn't get the idea, so if I want to delete message I should call smth like this:

say(nil, thread_id: 'THREAD_ID', delete_message: 'MESSAGE_TS') right?

In my use case I delete a mssg as soon as I send another one.. so I pass the mssg content as well. Check PR on Mav

[kladaFOX]

yeah I get it you are calling
say("blablabla", thread_id: , delete_message:)
But why not implement delete_message(message_id)?
And your case would be more readable. You will call say and then delete or vice versa.
I also think that having the delete_message method would be better for future use cases

[matthewblack]

I think we need both (eventually).The use case that Emilie implemented is the suggested use case for deleting and replacing a message one API request, which she is doing with her branch. I also noticed it was called out in their API docs. Correct me if I’m wrong on that Emilie.I do agree though that we should implement a ‘delete’ stealth method, but we can do that later.Sent from my iPhoneOn Dec 24, 2024, at 10:08 AM, kladaFOX ***@***.***> wrote: yeah I get it you are calling say("blablabla", thread_id: , delete_message:) But why not implement delete_message(message_id)? And your case would be more readable. You will call say and then delete or vice versa. I also think that having the delete_message method would be better for future use cases —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[emorissettegregoire]

Yes, thank you guys. I agree. Will check it with fresh eyes and see if we need both.

[matthewblack]

Hey @emorissettegregoire - Sorry for the confusion earlier. I took a deeper look what you're doing with this delete_message argument via the stealth-slack client.

I was initially under the impression that this was one API call to slack and that's how they handled "replacing a message". However, it looks like you are sending two API requests - one for creating the message, and then another for deleting. This violates the Single Responsibility Principle (SRP) and I agree with Ilya that we should create a separate reply handler called delete and inside our Stealth app, we should call both.

The goal in Stealth is to make each function modular which makes it easier to maintain. Moreover, separating concerns makes it easier to test, debug, and extend functionality. For example, if we ever decide to introduce new deletion-related behaviors or parameters, we wouldn’t have to modify the say method and risk affecting unrelated logic.

Let me know if you want to chat through any implementation together! Happy Holidays!

[emorissettegregoire]

Hey @emorissettegregoire - Sorry for the confusion earlier. I took a deeper look what you're doing with this delete_message argument via the stealth-slack client.

I was initially under the impression that this was one API call to slack and that's how they handled "replacing a message". However, it looks like you are sending two API requests - one for creating the message, and then another for deleting. This violates the Single Responsibility Principle (SRP) and I agree with Ilya that we should create a separate reply handler called delete and inside our Stealth app, we should call both.

The goal in Stealth is to make each function modular which makes it easier to maintain. Moreover, separating concerns makes it easier to test, debug, and extend functionality. For example, if we ever decide to introduce new deletion-related behaviors or parameters, we wouldn’t have to modify the say method and risk affecting unrelated logic.

Let me know if you want to chat through any implementation together! Happy Holidays!

@matthewblack on it. Thanks!

[kladaFOX]

Lovely!

[matthewblack]

Hell yeah! Great work Emilie.