REPL: rewrite as a component (or reuse something else)

[hzoo]

At minimum we can refactor this script into something that uses something like preact/vue? It's just getting more and more annoying to deal with atm. We don't have to rewrite the whole site just that file. https://github.com/babel/babel.github.io/tree/master/scripts in repl.js (and 7.js since I just made that to make something show up).

Or we can just use the preact repl @developit?

Can do this independently or with doing #858 (being able to use any package/babel plugin on npm)

• https://github.com/babel/babel.github.io/blob/master/repl.html (uses a few js scripts https://github.com/babel/babel.github.io/blob/master/repl.html#L7-L15) like jquery, lz-string, ace (could switch that for something else like codemirror/monaco if easier)
• https://github.com/babel/babel.github.io/blob/master/scripts/repl.js
• ideally we can move 7.html and 7.js which I forked so you could have a dropdown for versions but I guess this would be covered by Allow loading babel-standalone from CircleCI to enable easy testing of PRs #1284 which would give us query params for babel versions. cc @Daniel15

[Daniel15]

What's the advantage? Is it mainly to simplify the handling of the presets menu? A lot of the code in the REPL is not related to the UI and so would not change if it switched to using a different front end framework. It's probably still worth doing though. Babel itself is several megabytes, so it's likely people hitting the REPL wouldn't care too much about slightly more JS to load. :)

Using React or something similar would require adding a build step to compile the JSX, which would either require ugly hacks (checking in build artifacts to source control! Icky) or switching to a web host that has more features than Github Pages (which has a feature set likened to 90s-era Geocities). We use Netlify for the Yarn site and it's pretty good. They let you add custom build scripts.

Sent from my Samsung SAMSUNG-SM-G925A using FastHub

[Pokom]

I forked the project and will spend the weekend grokking the REPL codebase. In the meantime, any advice or context on where I should begin? This might be a bit outside what I'm comfortable building in terms of a project, but I'd be more then willing to work on it if someone has some time to mentor me a bit.

[hzoo]

Just seems easier to make it better as a component (or if the whole thing was a component then it's easier to add other UI, etc)? Yeah size it's really a concern since babel itself is large. The repl itself is just like 1 file anyway atm.

[tkh44]

FWIW the emotion example site uses a custom version of component-playground that has custom babel plugin. Might be a good reference for anyone wanting to try this.

https://github.com/tkh44/emotion/blob/master/example/src/preview/index.js#L10

[hzoo]

@tkh44 awesome, that's a good example! I realized we do that for a "preset" https://github.com/babel/babel.github.io/blob/master/scripts/repl.js#L31 too. But yeah I think what we want (more #858 though) is being able to import any plugin

[sibelius]

@princejwesley is doing an awesome job with this repl:
https://github.com/princejwesley/Mancy

[ryaninvents]

Using Monaco as the editor might incentivize VS Code extension development for Babel codebases, since they support similar interfaces for language features. Also, if there were some VS Code functionality that would be useful to the Babel REPL, it would be relatively easy to bring it in. (It's too bad that Atom's text editor component isn't exposed as a package, or that would be another option.)

I know you're not looking to create a fully-fledged IDE or anything for the REPL, but it would be neat to have some interoperability.

[Daniel15]

A good first step here might be to modularize the existing repl.js: Pull UriUtils, StorageService, the actual REPL execution/evaluation, and the loading of Babili into their own JS files. In #1284 I added a lazyLoadScript function to the Babel 7 REPL as a generic reusable replacement for the hasBabiliLoaded function in repl.js.

Basically, pull everything that's reusable into their own JS files, so that the only thing remaining in the core REPL file is the actual UI itself. This makes it easier to see exactly which code will be rewritten if we convert the REPL to be a component.

[hzoo]

That's a good point, all those are isolated thing anyway. Ideally, we could just reuse astexplorer since it already is written as a component but it would be a large refactor to figure that out fkling/astexplorer#70 but even https://twitter.com/ritz078/status/893616659864276992 is a component and transforms using babel

[bvaughn]

I'm playing around with this as well. 😄

So far, I'm leaning towards CodeMirror- probably a CDN build, maybe pointed at the same version Prettier is using, to cut down on load times across common tooling.

Not quite ready to share what I've built but wanted to leave a comment here since there seems to be some good running discussion.

[Daniel15]

So far, I'm leaning towards CodeMirror- probably a CDN build,

Yeah, CDN build sounds reasonable... I don't see any advantage of building our own custom version of CodeMirror given we can likely use it as-is with no modifications.

[bvaughn]

Yeah. What I've created so far is a slim React component wrapper around CodeMirror (similar to JedWatson/react-codemirror). I think pulling component pieces from CDN rather than bundling them in is a nice idea, since so many of these REPL-type-tools could then share cached assets.

However it seems like we're currently using a mix of unpkg (babeljs.io) and cdnjs (prettier.io) which would be nice to find consensus around.

[Daniel15]

Sounds good @bvaughn! 👍

What I've created so far is a slim React component wrapper around CodeMirror

Doesn't the React site have one of those too, for the various examples? The HTMLtoJSX page (http://magic.reactjs.net/htmltojsx.htm) uses it too.

I think pulling component pieces from CDN rather than bundling them in is a nice idea, since so many of these REPL-type-tools could then share cached assets.

Even if someone only uses the Babel site, pulling components from a CDN makes the caching more effective. It usually doesn't make sense to bundle code that changes frequently (like the code for the site itself) and code that changes infrequently (like vendor files - React, CodeMirror, etc) in one bundle, as any change to the frequently-modified assets will require users to download everything again, including the infrequently-modified assets. One solution is to configure a separate "vendor" bundle for this, but pulling the vendor files directly from a CDN gives you most of the same benefits, and HTTP/2 means that loading multiple files is not really much of an issue any more. Loading thousands of little files is still bad, but loading a dozen files is totally fine.

[bvaughn]

Doesn't the React site have one of those too

The React site is being rewritten 😉 (also by me). Maybe there's opportunities to share there, but the amount of code in this wrapper is minimal to the point of probably not being worth it.

Even if someone only uses the Babel site, pulling components from a CDN makes the caching more effective. It usually doesn't make sense to bundle code that changes frequently

Agreed! Although I think it's still worth trying to pick a CDN and standardize between the various REPLs.

[CompuIves]

I recently created a React wrapper around the monaco-editor with proper JSX support. This will give us Intellisense/type autocompletions and a vscode like experience. I'm planning on open sourcing it somewhere next week.

Maybe a bit overkill, but also an option 😄.

[bvaughn]

Just a quick update: I'm almost ready to submit a PR for this.

• Demo is accessible here
• Code is here.

I think there are only 2 TODOs remaining:

• Support babel-present-env plugin; (mostly just create the UI for its config options)
• Fallback to localStorage if query params are missing

I will try to finish these today and submit a PR.

[Daniel15]

Awesome, nice work Brian! Feel free to add me as a reviewer when you submit the diff and I'll take a look :D Sent from my phone.

…

On Aug 7, 2017 8:53 AM, "Brian Vaughn" ***@***.***> wrote: Just a quick update: I'm almost ready to submit a PR for this. - Demo is accessible here <https://bvaughn.github.io/babel-repl/#?babili=false&evaluate=true&lineWrap=false&presets=react&targets=&browsers=&builtIns=false&debug=false&code_lz=GYVwdgxgLglg9mABAMTnAFASkQbwFCKIBOAplCEUgDwBCAhkQHw4CMATAMwC-VA9PUzxcgA&experimental=true&loose=false&spec=false> - Code is here <https://github.com/bvaughn/babel-repl/tree/master/src/repl>. I think there are only 2 TODOs remaining: - Support babel-present-env plugin; (mostly just create the UI for its config options) - Fallback to localStorage if query params are missing I will try to finish these today and submit a PR. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1287 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFnHQb2k7Y-KyCQmxYwivEMBWQkyB1Vks5sVzMLgaJpZM4Op-I3> .

[existentialism]

@bvaughn same! also, let us know if you get caught up with other things, I'm sure we (and/or others) can help with the TODOs!

[bvaughn]

Will do! 😄 If I can't get a finished PR to you today, I'll get a PR with a couple of "TODO"s

[hzoo]

I think it would be fine to even have it at a separate link like /repl2 and just iterate as we find things, closer to making it real the better

[bvaughn]

Okay. All TODOs have been addressed (I think) except for the env preset. I'm comfortable submitting a PR with that one remaining a TODO (for now) and then I can fill it in as a follow-up.

Next question is: How best to structure it? My current repl is create-react-app based. I'm not sure how best to fit it into the current Babel/Jekyll build process. Any tips?

[Daniel15]

I'm not sure how best to fit it into the current Babel/Jekyll build process. Any tips?

Make it run when make build is executed, and maybe add a make watch for dev purposes that runs Webpack's "watch" mode. Add the Webpack output directory to .gitignore. That should be it. Netlify is configured to run make build so that should all work fine once we move the live domain across (the PR preview will definitely work).

I'm not sure how well create-react-app handles pages within existing sites. It seems like it's more designed for bootstrapping a brand new site rather than retrofitting an existing one. I don't think we need to bring the whole of create-react-app along with the REPL. A basic Webpack + Babel configuration should suffice. I don't know much about how Webpack is configured on the Yarn site but perhaps that's a good example? https://github.com/yarnpkg/website/blob/master/webpack.config.js

[bvaughn]

Thanks for the link @Daniel15! 😄

I guess my main remaining question was where to store the source since the _site folder seems to contain distributable stuff. Maybe something like this?

.
├── _site
│   ├── repl  # current REPL source
│   └── repl2 # new REPL build output
└── src
    └── repl2 # new REPL source

I'm not sure how well create-react-app handles pages within existing sites. It seems like it's more designed for bootstrapping a brand new site rather than retrofitting an existing one. I don't think we need to bring the whole of create-react-app along with the REPL.

I'm not sure I understand the concern of bringing in all of CRA but I'm open to suggestions if we think it's overkill. It makes for a nice development experience. I have the project setup to work with Flow and Prettier too. If we decided to move more parts of the Babel site to React in the future, CRA seems like a nice solution. But... I'm not set on it.

[existentialism]

@bvaughn works for me, we can do some renaming/cleanup when we replace /repl with /repl2

[Daniel15]

That sounds reasonable. _site contains the built site, including all the compiled JS, and the pages built by Jekyll. When the site is deployed to production, just the _site directory is deployed.

The Babel site at the moment has so little JS that you can probably just make up a directory structure and it'll be fine :P

Sent from my Samsung SM-G950U using FastHub

[bvaughn]

I created PR #1297 with some open questions and TODOs. Let's talk more there. 😄

[bvaughn]

Closing by way of #1297! Follow-up work detailed in the "New REPL" milestone.