We talked about this in a previous thread but I’m now pretty sure this is a good idea and it seems easy to implement. You know the “Show Live” button?

I think it should be split into a button and checkbox.

The button part would be the same as now but I think it should be labeled “Launch/Refresh App” rather than “Show Live”. [1]

And the checkbox would be the “Refresh App on Changes” checkbox currently tucked away in the user menu. It could be called “Auto-Refresh” or “Auto-Refresh As You Type”. The juxtaposition with the button would make it pretty quickly self-explanatory.

Why it’s important

Whenever my app gets bogged down, typically due to my own bug or boneheadedness (or sometimes legit computational intensiveness), it brings the IDE to its knees and it’s super frustrating. Having a quick way to toggle Auto-Refresh and always be aware when it’s toggled on would be pretty great.

You’d think it wouldn’t be a big deal to toggle it from the menu but I tend to wait till I’m pretty frustrated with lagginess before I do. Not so much because of the two extra clicks (open menu, toggle, close menu) but because when my app is snappy again I really want Auto-Refresh back on but I forget that it’s off and have a new round of frustration that it’s not refreshing as I type. Or just the uncertainty about if I should expect my changes to be magically reflected – it keeps making debugging harder than it should be.

In conclusion: I really want a visible indicator that Auto-Refresh is happening and a one-click toggle of it.

PS: What if you solved editor lagginess completely, so the editor is never hung up no matter what the app is doing? I argue that even then this is worth doing. Having the app reload itself over and over as you type is sometimes going to be unwanted behavior no matter what. So a quick way to toggle it and know when it’s supposed to be happening is valuable.

Footnotes

[1] And maybe it’s also easy for the button label to dynamically change between “Launch App” and “Refresh App” depending on whether there’s already a tab connected showing the app. It’s common to lose track of whether there’s already a connected tab, or maybe it crashed and lost its connection to the IDE. Anyway, this footnote is the least important part of my proposal!

Are you toggling autorefresh on and off again in the same project regularly? What are you typically doing that causes your cycle of laggyness and speed ups?

The original reason that the toggle is currently in the menu is because our observations implied that auto-refresh was something once you turned off, you wouldn’t really turn on again.

One of the most common scenarios being that when your project is new and fresh it builds instantly, but once you have multiple collaborators, or you add new endpoints, and your project grows larger and takes longer to build, manual refresh becomes the best way to go. In this scenario, toggling off auto-refresh is more of a one way street then a back-and-forth operation.

In an ideal world, the editor would never get laggy. The constraint we’re working with in this particular case is that when a window (the editor) opens another window (your app) with the ability to refresh it, those two windows share the same system thread. What that means is that when your app goes crazy, it starts to block the editor.

Manually refreshing the app breaks that link and allows each browser window/tab to use their own process.

Are you toggling autorefresh on and off again in the same project regularly?
What are you typically doing that causes your cycle of laggyness and speed ups?

I am! Lately it’s been due to apps that are computationally expensive on the client side. Like drawing fractals and such a la http://chaosgame.glitch.me but I feel like lagginess from auto-refreshing can happen on most any app and I’m very often wishing for an easy toggle. Maybe sometimes there’s unrelated lagginess but then we’re back to the uncertainty argument: the quick auto-refresh toggle would let me easily rule out “app is going crazy” causes of lagginess.

pketh:

The original reason that the toggle is currently in the menu is because our observations implied that auto-refresh was something once you turned off, you wouldn’t really turn on again.

Definitely not the case for me! Even without the editor lagginess issues, whether I want auto-refresh is highly dependent on what I’m doing. For tweaking CSS and such it’s super nice to have that instant feedback, even when it’s otherwise unwieldy.

pketh:

Manually refreshing the app breaks that link and allows each browser window/tab to use their own process.

Right, I never want to break that connection because I want to toggle auto-refresh back on as soon as the app is not going crazy. Or at least when doing visual tweaking where I want the immediate feedback. It feels like a pain to launch a new tab each time. Maybe especially because I always want to move it to a separate monitor. So keeping the connection and easily toggling auto-refresh feels like the best of all worlds.

ok i’ve been thinking about this for a bit, here’s a possible approach:

we add a keyboard shortcut for toggling on auto-refresh

we add a notification that shows you the current state of auto-refresh when you use the shortcut (e.g. auto-refresh is on)

the way this potentially adapts to your use case:

as you code you could jam the shortcut, you wouldn’t know the auto-refresh state but you could just hit it until the value you want/expect shows up (on or off). Once you get into a groove with it, you could do this fluidly without taking your hands off the keyboard as well

I was having the same feedback and my search brought me to this topic. I agree with dreeves on
"I really want a visible indicator that Auto-Refresh is happening and a one-click toggle of it"
My thought was to have a ‘Pause’ button next to ‘Live’ button, which when pressed will suspend auto refresh. And when I say it suspends Auto refresh, it will not only stop refreshing the live app, but also stops trying to re-build the app. Because, when I plan to make many code changes, I don’t want the console logs to be filled with known errors.

Looking at this forum, looks like there are many people who would want that feature…