Initial development of Gleam playground

[isaacharrisholt]

See gleam-lang/gleam#2557

TODO:

• Page generation
• JS compilation/execution
• Home page design
• Show compiled JS
• Share button
• Show compiled Erlang (closes Show compiled Erlang #2)
• Format button
• Example projects
• "About the playground" page design and content

---

Discussion

Share button

For the share button, I was thinking of potentially encoding something like the following as JSON:

{
  "version": 1,
  "files": {
    [
      {"file":"app.gleam","content":"<some gleam code>"}
    ]
  }
}

This would need compressing to keep query string length down.

This will allow us to expand the playground later to include multi-file projects so people can experiment with project structure and so on, and keeping it versioned will help maintain backwards compatibility if this changes in the future.

Example projects

It would be good to have some short example Gleam projects, like the Go playground has, to show off the sort of stuff you can accomplish with Gleam. Let me know if you have any ideas!

[inoas]

For sharing the query string length is very precious and thus I would not do that. I would include a g=1 in the QS maybe so if gleam 2 happens the playground is usable for both.

Also escaping gleam code into json adds a lot of string length.

for a download/upload feature + multi module tabs the json structure looks great <3, I'd still include a gleam version and I am uncertain about deps.

[inoas]

The QS len is so precious because people might start sharing code snipplets on discord and we would want to limit the length of that strictly I suppose?

[isaacharrisholt]

Oh it would definitely need compressing. One sec, let me make sure to add that to the description

[inoas]

The old playground has some query string compatible compression feature that can be just copied over I guess.

[inoas]

However, that only helps "so much"

[isaacharrisholt]

Agreed, but it means we don't need a database etc. We could definitely go the GitHub gist route, like the Rust playground, but that would require a backend with GitHub access. This way we can keep using a static site. Open to other ideas though!

[lpil]

It needs to go in the hash/fragment, not the query string. There are very tight restrictions on query string length which mean it is not usable for this, but there are no such restrictions on the hash/fragment.

Formatting and examples are not a goals of this first version, and I think we can skip the about page too. Less is more and shipping faster is best.

btw you've committed the public directory by mistake. Could you remove those files from the git history please before merging 🙏

[isaacharrisholt]

Ah, thanks for the advice! Very helpful.

Also, history should now be public-free!

[isaacharrisholt]

@lpil should be all good to go. I've left out Erlang compilation for now, as it would require also including the Erlang stdlib, and that's a larger piece of work. I'll create issues for the missing features.

[lpil]

Nice! I've left one large-ish comment on the approach here

[lpil]

Move this into Gleam code please 🙏

The tour uses text files for content as a sort of poor-person's CMS. This is not a content based site so let's keep everything in Gleam.

[lpil]

These have been removed so don't need this special case any more

[lpil]

Debug message left in here

[lpil]

Debug message left in here

[lpil]

Let's remove all the file system reflection based CMS stuff. We can just render a string of HTML and write it directly.

[isaacharrisholt]

@lpil all sorted, I believe!

[lpil]

Could you remove all the page abstraction stuff and build and write the HTML directly please. This project doesn't need a CMS so we don't want to port all that stuff from the tour 🙏

Something like this:

    use _ <- result.try(reset_output())
    use _ <- result.try(make_prelude_available())
    use _ <- result.try(make_stdlib_available())
    use _ <- result.try(copy_wasm_compiler())
    use _ <- result.try(write("index.html", page_html()))
    Ok(Nil)

[isaacharrisholt]

Ah, gotcha! Yes, I can do that.

[isaacharrisholt]

I think it's still worth having a page_template() or similar function, though. We may want to add an about page or similar later, no? Or can we guarantee this project will always be a single page?

[isaacharrisholt]

Hey I've been playing around and I'm not entirely sure how you want this to look. I think ultimately we need to keep a lot of the PageConfig, HeadConfig etc. otherwise we'll just end up with some massive function defining all the HTML for the page, and I don't think it'll be readable.

I remove the get_pages function and change it to need a single write call for each page like you suggested, but I'm not sure what that really achieves? All get_pages does really is define the output settings for multiple pages. If we changed it, we'd just be spreading this config throughout multiple functions.

[codemonkey76]

I've been playing around with it and there is an issue with the share link generation, it doesn't url encode the title, so if there are spaces in it (like there is in the default "A Gleam Playground project", then the link won't work

static/index.js, line 202:
you need to wrap the title in encodeURIComponent(originalString);

[isaacharrisholt]

I've been playing around with it and there is an issue with the share link generation, it doesn't url encode the title, so if there are spaces in it (like there is in the default "A Gleam Playground project", then the link won't work

static/index.js, line 202: you need to wrap the title in encodeURIComponent(originalString);

Fixed, thank you! I managed to overlook that because you can paste spaces into Chrome, but totally forgot that these links are made for sharing and wouldn't be clickable 😅

[codemonkey76]

I have it up on gleam-playground.fly.dev for testing

[isaacharrisholt]

I have it up on gleam-playground.fly.dev for testing

Thanks for that! Is it the latest version? It doesn't seem to have the encoded URI component.

[codemonkey76]

no it wasn't... just pulled your change and re-deployed it.,