Add live preview field

[Jack-McKalling]

It would be very convenient if the application would show a preview field upon selection of a message. This way you can verify that you selected the intended message before you copy it, so that if you're a new helper or a forgetful one, you don't need to paste the message elsewhere before you know what message you're dealing with.

Additionally, if the message requires additional parameters, upon filling in any information for those, the preview field should automatically update and show the changes to the message with this information already included, without clicking any additional button. This way you can also instantly see what the extra information you fill in does to the message.

This would make the application more intuitively designed and slightly more convenient to use.

I imagine this preview field being a textarea that is javascript controlled. If it is left as editable, one could optionally manually modify/adjust the message before use, but that would preferrably also require a refresh button to reset said changes to what the form would produce by default.

[bemoty]

I really like this idea, but I wasn't yet able to find any OpenSource JavaScript renderer for JIRA markdown, only this: https://github.com/tarleb/jira-wiki-markup

I also found something called "Twixi", which seems to be the name of the comment / text field renderer JIRA uses

[Jack-McKalling]

If all else fails, it would already be helpful if the preview is just the raw text of the message.

[Marcono1234]

Jira has a REST API endpoint for converting the markup to HTML, see this answer, and that seems to work fine (even without authentication). The only issue is that the CSS rules from Mojira are missing.

So maybe we could either do:

1. During deployment pre-generate the rendered messages and then use them later. This would reduce the REST API requests to Mojira and make the result a bit more predictable. However, this would mean that some variables in the messages cannot be filled in in the preview (probably acceptable). And we might run into rate limiting for the REST API during generation of the rendered messages during deployment?
2. Dynmically generate the rendered messages when the user selects a message. This might cause issues with including CSS rules in case the Mojira CSS rules are updated and our stored ones become outdated (see below).
   Edit: Does not seem to be possible due to missing Access-Control-Allow-Origin CORS header.

The Jira CSS files don't seem to have any deterministic URLs, so maybe we could add them to the repository once (edit: probably not possible due to license / copyright issues?) (except for https://launchermeta.mojang.com/mc/jira/mojira.css which we could load dynmically). And then we could maybe include the rendered message in an iframe with these CSS files applied.

Not sure if that would be a good approach, I am not so familiar with HTML and CSS. What do you think?
Of course, as mentioned by Jack we could also just preview the raw text.

[Jack-McKalling]

A correctly formatted preview would be nice if it could be made to work.
But a simple editable textarea should be a no-brainer to implement (i.e. a textarea cannot show formatting)

[Marcono1234]

Have created a proof of concept for this in branch poc-message-preview. However, there are the following open questions / issues:

• CSS and HTML and JavaScript code probably does not follow best practices
• Are we legally allowed to refer to Jira CSS files?
• Jira CSS files seem to have non-deterministic URLs; might break when URLs change in the future, until GitHub page is re-deployed

Feedback regarding any of these points is appreciated! To test the changes:

1. Clone the branch with Git
2. Run npm run build
3. Open the file dist/index.html in your browser

Though maybe this is overkill and as mentioned by Jack a simple textarea would suffice as well...