Edit: message.content always returns a string

[maximatically]

Not to sure but this could be a simple fix for system messages having "no message content".

Everytime someone uses the client.on("message",...) function they have to include a check if message.content even exists when wanting to work with message.content since if you don't the program breaks every time it recieves a system message/a message with just an attachment, which returns a message with undefined content. In my opinion making message.content always return a string is a better alternative to undefined. It would make using revolt.js more convenient for most of the developers.

Edit: If there are any other valid reasons for making message.content undefined you can close this but in my opinion this is a good fix for the current problem system messages cause.

Also since messages with just attachments can be edited and then have message content changing their content to be a string but empty would also make sense.

Please make sure to check the following tasks before opening and submitting a PR

• [x] I understand and have followed the contribution guide
• [x] I have tested my changes locally and they are working as intended
• [x] These changes do not have any notable side effects on other Revolt projects ¯\_(ツ)_/¯

-> These changes could potentially break a very small number of Revolt projects but all they would have to do to avoid this is changing the code that checks wether message.content exists to checking message.content's length.

[Rexogamer]

I feel like this is somewhat unnecessary - it doesn't seem that costly to check if message.content is null

[maximatically]

I feel like this is somewhat unnecessary - it doesn't seem that costly to check if message.content is null

True but in my opinion having one general response type would just make it easier to work with revolt.js. I just don't see a need for using undefined when the only real use case is to avoid it.