(feature request) Code/Live vertical separation about repl HOT 26 CLOSED

Here is my new proposition.

from repl.

Re-adding the ability to modify the JavaScript is easy: https://github.com/fable-compiler/repl2/blob/master/src/App/Main.fs#L448

I am in favor of read-only mode but open to suggestion because in general, I rarely explore the generated JavaScript :)

from repl.

Indeed Firefox is very slow. I compiled the same template on the same machine with Chrome:

Hello world sample

Color foutain sample

Last time I checked the difference wasn't that hight but I should definitely work on REPL with Chrome and Firefox (less loading screen^^).

Edit: I will add a warning mentioning that chrome can be much faster than Firefox for the REPL.

from repl.

+1 for moving the Fable logo and the compile button to the top of the toolbar on the left, would free a lot of vertical space at the top.

from repl.

but it can be hard to understand that they are button and not menu.

The collapse button on the same toolbar (at the bottom) for example is a button and not a menu, so perhaps something similar can work.

from repl.

@MangelMaxime It's awesome, just two minor things:

• Are the reset and "refresh samples" below it different somehow? Can they be merged into just a single reset button (without confirmation, IMO there's not need for that)?
• Also, samples are already separated in a category, perhaps the second "SAMPLES" title can go away and the list alignment can be pushed left a bit.

I like it a lot, very clean design.

from repl.

@ncave Ah no, you can ignore this button. This is something only displayed in dev mode in order to reload the samples information without reloading the whole tab. Allow us to have a quick feedback.

from repl.

Other possible layouts here: https://webassembly.studio/
Treeview on the left, merged problems/error panes at the bottom.
Not that we have multi-file capability yet, but something to think
about in the future once storage is figured out for the link sharing.

from repl.

Originally, I was planning to add the console output in the bottom right section. I am speaking about the console coming from the iframe.

from repl.

As long as editors can be collapsed, I wouldn't mind to have this layout. I did find some glitches because of the hidden editor. If we implement this, I guess we should also add a mechanism to edit and reload the JS code without recompiling F#.

The console output is tricky, in Chrome everything goes to the same console, so I can see there logs from worker, main app and iframe. But apparently it's not the case in other browsers. I'm not sure how the console output from the iframe can be redirected. In one of the first REPL versions I had some trickery for that, but it involved replacing printfn calls.

Anyways, now that we have Elmish & React in the repl, it should be also easy to include by default a component that can show logs in the web page.

from repl.

I guess we should also add a mechanism to edit and reload the JS code without recompiling F#.

Not sure to understand this part, the JS code shouldn't be edited by the user and I made it readonly for this reason.

The console output is tricky, in Chrome everything goes to the same console

Same for every Firefox, but the trick is to listen to provide a custom console implementation in the iframe and use it to catch the logs and send them back to the main window via an event.

from repl.

Not sure to understand this part, the JS code shouldn't be edited by the user and I made it readonly for this reason.

In the very first REPL it was possible to edit the JS code and run it again. This was sometimes useful to see how the JS generation could be improved.

from repl.

IMO the javascript could be read-only, as it was generated, at least in the initial release. I'm not sure if there is any value of showing console output, that's what F12 is for. Perhaps the compilation logs can go to the generated code window if there are errors during the compilation. But these is just my thoughts as a user, not a UX guru, so don't put much weight on it.

from repl.

My problem with using the F12, is that it take a lot of place :)

Where adding a specific panel for it take less space. And this panel, could indeed contains the logs too.

from repl.

In the last couples of days, I thought a lot about this issue. And I can see 3 separated use case for the REPL:

1. The user wants to play with the REPL and do some visualization stuff.
   • Mainly interested in the Live sample tab
   • Can sometimes be interested in the Console output for debug purpose. Like printing variables values
2. The user wants to check the generated code.
   • Only interested in the Code tab
3. The user wants to test some code, see if Fable supports it, etc.
   • Mainly interested in the Console

So I propose for now to provide 3 tabs on the right panel:

• Live sample
• Code
• Console

Or to have a split layout on the right panel:

• Top part
  • Live sample
  • Code
• Bottom part
  • Console

The bottom part can be expanded/collapse in order to maximize the available space.

What do you think?

from repl.

Displaying the console below the Live Sample/Code probably would be very helpful for users. How are you planning to do it? By overwriting the console value?

from repl.

@MangelMaxime As we're trying to maximize the space, should we remove the top bar and just put the Compile button in the collapsible menu?

from repl.

from repl.

Well, I think so, because new users may not know the key shortcut and some people may even prefer it. If you're talking about automatic compilations every X seconds, for now I'll avoid that because the big samples getting close to 1000 lines can take some seconds to compile.

from repl.

How are you planning to do it? By overwriting the console value?

I will wrap the console function to capture their call to send them back into our Application and then trigger the native implementation. I made a quick POC this morning and it seems to be working.

Do you even need a compile button?

We do need the compile button because compilation is slow, so we need this action to be triggered by the user.

Hello world sample

Color fountain sample

The navbar don't take that much place but I will see if I can place the button somewhere else. Because I also want to add a Reload button who just reload the Live sample this is usefull when you want to check runtime performance or have some random in your simulation like generating a random image etc.

from repl.

22 secs to compile the fountain sample! 😮 Wow, Firefox is really slow! That sample can compile in less than one sec in Chrome in my machine if it has no pressure from other apps. Also in my machine, Firefox compiles it in 8s (without pressure).

from repl.

Indeed we gain some space but it can be hard to understand that they are button and not menu.

Will try different layouts and see/share the results.

from repl.

I don’t think this is the same case.

When the sidebar is collapse this button is separated from the rest. And when extended it have the same design has the widgets headers with a text to inform that there is an action.

Even like that this is not always clear that you can click on it. The visual feedbacks are really smalls.

We need to make sure that the compile & reload button are easily identifiable as button.

I just got an idea of using an outlined colored button so visually they are différents from the rest. Will try it

from repl.

Ok, I think using a different style is promising.

Need to fix the placement

from repl.

@ncave They are indeed different.

• Refresh
  • only re-run the iframe with latest jsCode received.
• Reset
  • reset the Html code and F# as if the REPL has just been loaded.

I need to add some tooltip to explain some of the action and probably rename the refresh button to Re-run or something like that.

from repl.

@MangelMaxime Not the refresh, refresh makes sense, I was referring to the "Refresh Samples" below, which seems unnecessary now, together with the "SAMPLES" title below it.

from repl.