Add support for LiveReload without browser extensions #43697
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
| */ | ||
| @Configuration(proxyBeanMethods = false) | ||
| @ConditionalOnWebApplication(type = Type.SERVLET) | ||
| class LiveReloadServletConfiguration { |
There was a problem hiding this comment.
This configuration contains Servlet-specific bits needed to set up everything. If something like this is a viable approach, I assume WebFlux-specific equivalent is needed as well (I've never used Dev Tools with WebFlux so I'm unaware if there are any limitations).
| private final String scriptSnippet; | ||
|
|
||
| public LiveReloadScriptFilter(int liveReloadPort) { | ||
| this.scriptSnippet = String.format("<script src=\"/livereload.js?port=%d\"></script>", liveReloadPort); |
There was a problem hiding this comment.
Perhaps something to consider is embedding the script in what LiveReload.js readme refers to as slightly smarter way, see https://github.com/livereload/livereload-js?tab=readme-ov-file#using-livereloadjs.
There was a problem hiding this comment.
This updates the existing livereload.js to latest version from https://github.com/livereload/livereload-js.
| @@ -284,8 +284,6 @@ If you find such a problem, you need to request a fix with the original authors. | |||
| == LiveReload | |||
|
|
|||
| The `spring-boot-devtools` module includes an embedded LiveReload server that can be used to trigger a browser refresh when a resource is changed. | |||
| LiveReload browser extensions are freely available for Chrome, Firefox and Safari. | |||
There was a problem hiding this comment.
Not sure whether it's needed to explicitly call out here that browser extensions are no longer needed and Spring Boot provides everything needed.
|
Unfortunately I think the filter might generate invalid HTML. If I'm reading the code correctly then it inserts the I guess the filter could parse the HTML and try to insert the script in the correct location. The problem there is that we might need to parse all responses just to tell if we're getting HTML. On top of that, the WebFlux side is also going to be pretty hard to address. Flagging for team attention in case anyone else has any bright ideas. |
philwebb
added
for: team-attention
That's true. I didn't (yet) put much effort into making the filter implementation robust as I wanted to pick up some feedback on the high-level approach first. Looking into what some other web frameworks do this shouldn't be too hard - for example Hugo injects the
The filter already takes response content type into consideration (requiring it to be |
I think it can't determine the content type until it's called the filter chain. That means we probably need to capture content for all requests in case they're HTML and need the script tag injected. |
|
Yes, but that (wrapping) is different than parsing every response - that can still only be done if the response indeed is I've experimented with my PoC project a bit and got something (again very simple, not robust) working using I've also pushed those changes here. |
This commit improves Dev Tools live reload capabilities by adding support for appending LiveReload.js script to rendered web pages. See spring-projectsgh-32111 Signed-off-by: Vedran Pavic <vedran@vedranpavic.com>
|
The filter should now work with any valid HTML and inserts LiveReload script element into head as the first child element even if the |
This commit improves Dev Tools live reload capabilities by adding support for appending LiveReload.js script to rendered web pages.
See gh-32111