search

RickStrahl / Westwind.AspnetCore.LiveReload

ASP.NET Core Live Reload Middleware that monitors file changes in your project and automatically reloads the browser's active page
Other
469 stars 42 forks source link

Configurable reconnection behavior #43

Closed NoahStahl closed 3 years ago

NoahStahl commented 3 years ago

Thanks for this awesome tool, it's fantastic for productivity in Razor Pages. I'm noticing one quirk, which is that when the server is stopped, the injected reload script continually retries the connection, by default with 0 delay. If you have the browser console open, you see thousands of errors and requests as the script frantically tries to connect and fails. I'm finding this visual noise distracting enough that I want to minimize or close the browser just to hide it while I'm working on the server code before restarting.

I've looked at the code and not sure I see a way for this to gracefully disconnect and not retry forever. I'd be happy to manually refresh the browser once I start the server again. Is there a configuration I'm missing to achieve this, or would you be open to a PR to add such a setting?

RickStrahl commented 3 years ago

The problem is that the server can go down a lot for code changes, so there's no easy way to detect whether the server is not actually there or whether it's just restarting or crashed because code won't compile - you want it to come back online when you get the code working again. So the code keeps polling for connections.

The WebSocket requests shouldn't be an issue really. They'll fire and fail. Unfortunately Web Socket connection errors aren't directly trappable in Javascript code and they fire a connection failure console error. The component also writes out a connection failure notice - I can remove the latter, but the native message will still show up and there's no way to stop that.

So I don't think there's a good way to do this nor am I sure that I'd want it to not work this way.

RickStrahl commented 3 years ago

Thinking out loud here:

I guess one thing we could do is set a fixed number of reconnection requests. Try 100 times (or x number of seconds) and if it keeps failing stop. Once stopped a refresh is required. Have the value set to 0 (no expiration) by default and allow config.

I still think this will cause unwanted behavior because if you are fixing code, that is broken you're almost certainly going to go over your timeout and then you'll be required to restart. I definitely prefer to just have it come back online. The fact that the console is throwing errors while the connection is gone is not really a big deal because if that's not working, the app is probably not running either so other than visual noise, it doesn't really interfere with anything.

NoahStahl commented 3 years ago

Thanks for the thoughts Rick. I agree this isn't causing a problem per se, it's really just an issue of the visual noise. I love not having to touch the browser in my second monitor during dev, but finding myself wanting to close it immediately to avoid the error stream made me wonder if there was a way to tweak it to play more nicely.

It is probably somewhat up to personal preference so configurability would be warranted in any approach. Capping retries and/or adding a delay seems like a step in the right direction. Silencing the errors would be ideal, but it seems like the browsers really want to show an uncatchable error in red font :).

The only idea the occurs to me would be to introduce a third component, an always on "live reload monitor" server process that runs separately (as a dotnet command line tool, perhaps, a la LiveSharp), which itself does the dirty work of watching for the target dev endpoint to come back alive, then pings the page script to reload. The page and monitor would have a continual websocket connection which would seem to avoid the intermittent offline issue. Of course, that's more complexity...

RickStrahl commented 3 years ago

The simple solution is to not run with the DevTools active :smile: in which case you don't see the messages.

NoahStahl commented 3 years ago

No worries, thanks again for the tool!

cleytoncoro commented 3 years ago

Its happens here too. And chrome displays thousands output errors per minute. And chrome hangs and interface stops to respond. My CPU goes to 40% of usage.

I think this don't happens with you all, but i don't know how to reproduce this.

Maybe a small delay, maybe 500ms, could be allow chrome to respond again and stops to hang.

And thanks for the work.