Sheffield | 25-SDC-Nov | Hassan Osman | Sprint 1 | Bug Report: Extra long blooms?

[HassanOHOsman]

Self checklist

• I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
• My changes meet the requirements of the task
• I have tested my changes
• My changes follow the style guide

This PR fixes AS's extra long bloom bug by ensuring it respects the 280-character limit. Changes include:

1. Trim bloom content on submission: Users cannot post blooms longer than 280 characters.
2. Trim bloom content when rendering: Any existing or backend-provided blooms are capped at 280 characters in the UI

[OracPrime]

Convince me of your approach (good luck!) or make it fail not trim!

[OracPrime]

I'm not convinced. Should too long a bloom fail, or should you truncate it and accept it? I think it should fail.

[HassanOHOsman]

To be honest, at the time I was in two minds whether or not to handle the too long bloom with an error which lead to it not being submitted. However, somehow eventually I resorted to chopping the extra characters. I perhaps thought this approach would me more ideal since it's already published bloom.

I understand now I have to fail it altogether. I will working on it. Thank you.

[HassanOHOsman]

AS bloom - the one over 280 character is now hidden. Not sure if it's the ideal approach but I did use the bloom id from the error message showed up on my browser and used it to skip over the culprit bloom when blooms are being fetched.

[HassanOHOsman]

I understand very well that, ideally, there should've been a condition that'd check if a bloom was over 280 characters and if so it'd be skipped over. Having said that this just didn't work for some reason when i did it.

[HassanOHOsman]

UPDATE: Well, it has worked now - I replaced the bloom ID-based logic to a conditional logic that checks if bloom is over 280 char and skips over it if that's the case. I had to disconnect from all ports and reconnect again.