[Compiler Explorer] Persist explorer state in the URL/local storage

[captbaritone]

This should allow the compiler explorer to be used as a mechanism for sharing minimal reproducible compiler bugs and other examples of compiler behavior.

The general idea is to consolidate all the state in the compiler explorer into a single object (Redux style):

• Schema
• Document
• Feature Flags
• Language
• Selected tab

And then (json) serialize and compress that state and persist it to the URL hash and local storage. Note that by using the URL hash we ensure the content of the explorer is never sent to the server, and thus the privacy of the content is improved.

Test Plan

Screen.Recording.2022-05-31.at.9.34.46.PM.mov

[captbaritone]

@orta Curious to hear if you have any thoughts/suggestions here.

[orta]

First of all, I love it (and kinda didn't know this existed)

There's three things I'd think about, which is largely about how the public interacts with these tools:

• A change which is a bit more effort but felt worth it for me, is to not merge all the URL's into a single blob, but to encode each individual part as its own query param from the diff of the defaults. It makes the URLs quite a lot more readable and more obvious that it represents the users state to folks seeing the URL for the first time.

  e.g. from 'compiler-explorer/#asdadadsdsfs' to compiler-explorer/#code=asdadadsdsfs?flag=on&other=false'

  Most of that code lives here

• Add a 'share' button on the page somewhere, even though the URL is there and obvious it is something which gets used far more than you would expect.

• Using pushState (or replaceState) on keychange will trash the users browser history, there are people who care about this. After a few years of push back I eventually opted to only update the state when monaco loses focus in the TS playground. This is enough for when you are going to copy the URL, and rare enough that it doesn't annoy history carers

[orta]

Worth thinking about from the other side too, the relay vscode extension could be able to have a way to generate a url of your schema (or the relevant subset) and the document you're looking at too

[captbaritone]

Thanks for the great feedback, glad I asked! We haven't publicized the Compiler Explorer yet because:

1. We don't have good internal CI to ensure the wasm build doesn't randomly break
2. It's currently manually deployed, so it gets out of date (potential fix)
3. There was no way to share the contents (this PR)

Once those problems are sorted out, we will likely include it more visibly in the docs.

Splitting up the URL sounds nice, and something that would be good to nail down initially rather than needing to migrate to. I'll take a stab at that.

Regarding history carers, I figured replaceState would be sufficient to appease them since it just clobbers the current history entry and does not end up creating a long tail of chatty history entries. I guess there's more to it than I realized?

Share button's a great idea. I'll probably punt on that one until a different PR though.

[captbaritone]

Integration with the VSCode extension is a super interesting idea. I think the main challenge would be figuring out how to trim the schema down in a representative way, since I suspect most schemas are too large to fit in a URL.

[orta]

Yeah, it doesn't seem to unreasonable to me that you could take a query, then only get all relevant types used in that query and jam that into a URL, which could probably be OK - there's a limit, but memory serves that is around 4k of text. I'm sure F will have queries with types bigger than that even after gzip, but I would be surprised if that was the majority of queries

[facebook-github-bot]

@captbaritone has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.