Initial POC of Message Type provider system #46
Conversation
This is a POC where message types are moved into service provider/facade allowing for the expansion of the type system by implementing system. This isn't complete but the tests are passing! What's been done: Message type specific Resource data methods have been moved into type classes. This removes type-specific code from the resource. Most of the hardcoded references to type codes have been removed and replaced with a Facade getter. Definitions for system and non-system types are now defined in the MessageType repository. Relevant tests have been updated. There are a number of bits and pieces for the document/audio/image types which haven't been moved over and might require a bit more thought as to how they are going to be handled. Things like `->isImage()` shouldn't be necessary, but should be handled better. There are a handful of `Message::*` for non-system messages that haven't been touched yet. I just don't want to flesh everything else out if this isn't a good direction.
|
Thank you for this wonderful POC @nvahalik I will leave this PR as it stands and see how closely this may fit into my rewrite, of which I am starting within the next week or two. |
|
I would greatly appreciate if we could figure out an approach that you might be comfortable with as we are planning on moving forward with this and we'd prefer not to make a hard break from the code. An 80% solution (allow for creation of new message types without having to modify the core library) is essentially done—but getting to the final 100% where all message-related functionality is class based is going to take some additional consideration or trading off. Some stuff like images and documents which have their own endpoints may not be something which can be easily pulled out. Transformation of the message information is easy enough but offering points for sharing or different image sizes is a lot harder to make generic. Not sure it makes sense to handle stuff like that at this point. |
|
Updated with StyleCI changes. |
|
@nvahalik Understandable, I would just ask for a little more time :) Now referring to image/document/audio, I am still quite certain that I will remove all individualized endpoints for them, and a message will be more akin to discord, where it may or may not have attachment(s) along with optional text. I am also planning to remove my friends system as that does not fit into the SRP for this package I am trying to achieve. |
|
No immediate plan to implement this. Will revisit with official v2 at some point. |
This is a POC where message types are moved into service provider/facade allowing for the expansion of the type system by implementing system.
This isn't complete but the tests are passing!
What's been done:
Message type specific Resource data methods have been moved into type classes. This removes type-specific code from the resource.
Most of the hardcoded references to type codes have been removed and replaced with a Facade getter.
Definitions for system and non-system types are now defined in the MessageType repository.
Relevant tests have been updated.
There are a number of bits and pieces for the document/audio/image types which haven't been moved over and might require a bit more thought as to how they are going to be handled. Things like
->isImage()shouldn't be necessary, but should be handled better.There are a handful of
Message::*for non-system messages that haven't been touched yet. I just don't want to flesh everything else out if this isn't a good direction.