Discussing ideas
As of now the main idea is that index.html is SPA - meaning it does all work for loading/saving editor contents from/to the backend, staying lean and immutable itself.
That simplifies certain things at the expense of other things. Best part - it keeps highlighting task at the clients' side (which keeps worker code rather simple).
However it creates a number of problems:
- Visual hitch when page loaded 'empty' and then (if URL contains paste id) load and updates with that document.
- Its unlikely to be indexed as the content is dynamic and depends on JS to render. (Although there is /raw/ direct link to paste contents)
- Proper caching might be problematic
Other approach would be if worker on paste request /{id} would return a page with spliced in paste contents. Then here is a junction point where highlighting has to happen (and shall the dynamic highlight choice via changing '.ext' url part can be easily supported)
- Worker embeds raw paste into html, client (browser) does highlight pass
- Worker runs highlighting on 'save', embeds highlighted version into html (switching language now is a problem)
- Worker runs highlight on page request. Extra server load (although with some help we can cache highlighted result)
Discussing ideas
As of now the main idea is that
index.htmlis SPA - meaning it does all work for loading/saving editor contents from/to the backend, staying lean and immutable itself.That simplifies certain things at the expense of other things. Best part - it keeps highlighting task at the clients' side (which keeps worker code rather simple).
However it creates a number of problems:
Other approach would be if worker on paste request
/{id}would return a page with spliced in paste contents. Then here is a junction point where highlighting has to happen (and shall the dynamic highlight choice via changing '.ext' url part can be easily supported)