Currently, messages are rendered using a single tview.TextView. Since TextViews do not support editing its own text, any updates to messages can only be done by updating it all over again. This has 2 issues that, while not major now, will cause problems as the project grows in complexity:
Performance - having to update all messages for any kind of edit (be it as small as opening spoilers), will cause more slowdown as support for loading more messages is added (#308)
Overcomplicated code - any and all logic pertaining to editing messages has to pass through the creation process first. This means that if, for example, support for adding spoilers were added, it needs to be tracked separately so that the creation logic knows to render it as it should, rather than simply having to update a single message.
Proposal:
Create a new tview Primitive for handling and rendering messages. Here's how it will fix the above issues:
Messages will only be rendered as much as the screen can actually show, or a config limit. Any message updates will simply require a redraw for the actual message, rather than everything.
Everything pertaining to messages will be handled on a per-message basis within the code, and will not require some weird way of tracking what and where things are done. Want to open a message's spoiler? Just make it redraw only that message with them open.
ayn2op
commented
1 month ago
Currently, messages are rendered using a single tview.TextView. Since TextViews do not support editing its own text, any updates to messages can only be done by updating it all over again. This has 2 issues that, while not major now, will cause problems as the project grows in complexity:
Proposal: Create a new tview Primitive for handling and rendering messages. Here's how it will fix the above issues: