Would it make sense to refactor getQueryParameters() to use URL/URLSearchParams, so we don't have to maintain custom code over native one or do you prefer not to fix something that ain't broken?

By the way, this

function optionalLocalStorageGetItem(key) {
    return localStorage.getItem(key) ?? null;
}

and so can

theme = optionalLocalStorageGetItem("theme");
set_theme(editor, themelist, theme ?? "GitHub");

as well as

var themes = themelist.themes;
themes.sort((a, b) => a.caption.localeCompare(b.caption));

Then, we have

var classes = mappings[arguments[1]];
if (classes) {
    return '<span class="' + classes + '">' + arguments[2] + '</span>';
}
return arguments[2];

The following is an interesting case:

it could either be rewritten as

if (req.status == expect) {
    if (on_success) {
        on_success(req.responseText);
    }
} else if (on_fail) {
    on_fail(req.status, req.responseText);
}

or

if (req.status == expect && on_success) {
    on_success(req.responseText);
}
if (req.status != expect && on_fail) {
    on_fail(req.status, req.responseText);
}

Next, we have a bunch of these:

asmButton.onclick = compile.bind(window, "asm", result, session.getValue(), asmButton);

irButton.onclick = compile.bind(window, "llvm-ir", result, session.getValue(), irButton);

gistButton.onclick = shareGist.bind(window, result, session.getValue(), gistButton);

clearResultButton.onclick = clear_result.bind(window, result);

themes.onkeyup = themes.onchange = set_theme.bind(window, editor, themelist, themes.options[themes.selectedIndex].text);

request.ontimeout = set_result.bind(window, result, "<p class=error>Connection timed out" +
                "<p class=error-explanation>Are you connected to the Internet?");

One could possibly also refactor editGo(), editShowRegion(), editShowLine(), and editShowPoint(), but that'd be slightly more than a simplification.

Miscellaneous

• className vs classList
• fetch vs XMLHttpRequest
• setAttribute('data-*') vs dataset
• onclick vs addEventListener()

• STDOUT
• STDERR
• Exit Code

Without:

With:

As part of it, we can move the docker image builds into a pr.yml like we have in other repos.

Related to ponylang/pony-tutorial#546

This could be implemented statically into static/web.html at first, but it would make sense to prospectively make it dynamic by converting it to a template and creating the tags depending on the Query params.

• snippet file name?
• preview image of snippet, code, or gist
• extract docstrings from snippets and gists as description (could technically even be interpreted as frontmatter to support more than just the description)

I know, I'm crazy, but one should be allowed to dream every once in a while 😉

To verify that the playground (minus the frontend) is actually working, we need some integration tests to run upon every PR and merge to main:

• Running some piece of code after calling the API
• Compiling some piece of code to ASM/LLVM IR output
• OPTIONAL: sharing a gist using the github API - this one is hard to mock, actually.

For more information on how this is imagined to look like:

• https://doc.rust-lang.org/book/ch11-03-test-organization.html#integration-tests
• https://github.com/testcontainers/testcontainers-rs

Initial situation:

Reloaded:

This is the output of current master:

nightly-20191123 [release]
compiled with: llvm 7.1.0 -- cc (Alpine 8.3.0) 8.3.0
Defaults: pic=true
Building builtin -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/builtin
Building . -> /tmp/tmp.olfgho/main
Building collections -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/collections
Building ponytest -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/ponytest
Building time -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/time
Building random -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/random
Building itertools -> /root/.pony/ponyup/ponyc-nightly-20191123-musl/packages/itertools
Generating
 Reachability
 Selector painting
 Data prototypes
 Data types
 Function prototypes
 Functions
 Descriptors
Writing ./main.ll

expected output: the LLVM IR from ./main.ll and no compilation logs.

It would be finest if we had (headless) browser-based integration tests, verifying the basic operations this playground offers.

Any pointer on good tools to use here are very much welcome.