[Playground] Syntax Switching Poll


#1

Imagine you’d have a playground that allows switching the syntax… you write some e.g. Reason code that has some syntax errors in it, and you now try to switch the language via a toggle. would you expect…

  • the language to switch, no matter if an error is there (also showing an error that something is wrong on pos x,y)
  • the language to stay the same until you fixed the syntax error first
  • just switch the language without any warning at all

0 voters

Here a small Screenshot to get some feel of the UI:


#2

@jdeisenberg on discord:

Just thought of a case where A applies: you are writing the new res syntax but the playground has been set for re syntax. You want to switch to res, where your code will now be correct, but B wouldn’t let you.

Just cut your code into clipboard, change syntax and paste it back. Seems like a workaround, but how common would this usecase be? Does it deserve dedicated ui elements?

I think it would be nice to display a warning and let the user decide to procede while the syntax error is present which could result in “bad” code.


#3

I like the idea in the last paragraph - display a warning and let the user decide to continue or fix the error.


#4

Given enough code (need to experiment to find how much is enough) it should be possible to auto detect the syntax. Just try to parse using each of them and see which succeeds.

Considering that there are even keywords shared by the three syntaxes you could even provide special, limited, highlighting until the syntax is detected.


#5

I don’t really see the point of B, if you indeed want to convert only correct code, couldn’t you then disable the button with a hover saying you have to fix the error first? IMHO having a button that makes no changes is not great UX. Or maybe I misread and that’s precisely what was suggested ^^

I still think choice A is better, sometimes I copy paste some code in the playground just to see the JS or OCaml output, and very often the code snippet is not complete so there are unbound modules or values, it’s still nice to see how it would be written in the other syntax.


#6

I implemented Version B for reference:

To give some guidance on trying it out:

Copy this snippet into the playground

if 1 === 1 {
  2
}
else {
  3
}
  • Then, Click on the “New BS Syntax” toggle and select Reason.
  • Now you should see the translated Reason syntax
  • Toggle Back to “New BS Syntax”
  • Now remove some random brace to cause a syntax error
  • Try toggling to Reason

You will now see that the Syntax toggle is disabled, and errors will be displayed in the same manner you would see them when compiling malformed code.

Still not entirely polished, after changing some code, I guess the toggle should be usable again, otherwise you need to click “Compile” first before you can proceed switching to the other syntax


#7

After playing around with your mock-up I actually do like the experience quite a bit. I was otherwise mentioned I do think that is not too hard to copy and paste the code over.

Also maybe clicking that button triggers a recompile?

You could also potentially do a modal and ask the person what you want them to do, although that’s kind of a UX cop out.

I think I’m struggling with is that they switched from the old syntax for the new syntax (no auto transformation) it probably still work and they’ll get better error messages :grimacing:. Unless they use infix operators… Going the other direction wouldn’t be as pleasent though which would create a sub par experience.


#8

How big are the chances that switching the syntax on an erroneous piece of code will make the error worse?

Also, how much will variant 1 complicate implementation? If it does, maybe it’s not worth it. It’s a known phenomenon that users always need every feature if you just ask them directly, because for them every ”yes” is free, but it’s hardly ever free for the devs. That’s why some people recommend asking things like “would you rather have Feature A or Feature B”, etc.


#9

Playground is really shaping up nice. Some feedback:

  • Can we compile while typing. I guess the compiler is quite fast and it saves needing to click the button every time when you want to look at the other side (perhaps with a debounce).

  • I would be really interested in converting between two independent pairs of outputs. Now the right side is JS, but would it be possible to also choose the target there (Reason/Js/BuckleScript/OCaml). This would help tremendously as we have so many syntaxes that we need to translate between at the moment. Especially OCaml to Reason would be handy.


#10

It looks really nice - I love the colours!

My 2c though,

I think your language dropdown might be trying to do too much. It acts as an input language selector and transpiler. More confusing is it only acts as the input language selector when the document is empty.

Maybe you could make these two elements - an input language selector, and a transpiler dropdown button. Then you can disable the transpiler button (and format button) when there’s a syntax error.

Alternatively, you could do the single dropdown with a lot of handholding in the errors. Like,

A syntax error occurred at …
Change input language to reason
Change input language to ocaml


#11

Thanks everyone for the feedback!

There is an OCaml output tab on the design mockup, but after some design discussions we concluded that it shouldn’t be shown by default. So most likely there will be some kind of advanced mode toggle later on that will expose an OCaml output tab next to JavaScript.

Please note that this thread is solely discussing the syntax switching UX, most of the features / design you see right now are not done or subject to change. Compile while typing will eventually be implemented, but first I want to answer more urgent technical questions :smiley:

I thought about that as well, but I couldn’t think of a nice way to not make this confusing. The less clicks the better :slight_smile:


Since I refactored the BuckleScript Bundle API, I have way better access to fine grained information, therefore I started to change the way syntax switching works:

No matter the syntax correctness of the code, you will be allowed to toggle the syntax. In case the syntax cannot be parsed in the current language, it will not be translated. Instead, the playground will try to pretty print the new language instead. So either your code will translate successfully, or in the worst case, will show the syntax parsing error of the new language (Version A basically).

IMO now it feels right. Back then I didn’t have enough result information to implement that version in a satisfactory manner.

Here is a new build of the new error reporting / syntax switching mechanisms:

Let me know what you think.


#12

Ah ok so converting from Reason to Napkin and the other way around would be part of this? That is the most important thing as most code is still published in Reason and converting between them will be a problem for 100% of the users. I think OCaml would also be very good to have for beginners (and even myself) as you end up with OCaml examples a lot as well. Side-by-side would be nice, but not super important. Will the dropdown have an OCaml option next to the “New Bucklescript” and “Reason” options?

I know that this is not the final UI, and that is something to optimize later. But it would be better to have a “segmented” UI control instead of a dropdown for syntax switching that shows “New bucklescript”/ “Reason” / “OCaml”. That will be friendlier, so users can see the options without needing a click. It also are only three options, so there is plenty of room and I would suggest to put it at the top of the text box.