Callbacks (Feature Request)

[F1LT3R]

What version are you using? (Don't say latest. Be specific.)

0.6.0

Expected result

I would expect LiveReload to be able to for a callback when a certain kind of extension was changed.

Example:

const liveReloadServer = liveReload.createServer({
	port: 35729,
        list: [{
            ext: '.md',
            callback: () => { doSomething(); }
       }]
}).watch(dir);

Actual result

N/A

Steps to reproduce issue

Use the code above.

Why is this important?

Flexibility.

[napcs]

Im 👎 on this. The purpose of this library is to reload the files in the browser and be compatible with LiveReload. This is not a general-purpose "watch files and do stuff" plugin. You probably want something more robust than that.

I'll need something more than "Flexibility" for your justification. "DoSomething" is also quite vague. What specific use case are you trying to solve that other Node libraries aren't solving?

[F1LT3R]

I see where you are coming from on the 👎

The reason I enquired about this was there seems to be no way to say "reload page" (without explicitly referring to a file being used in the active browser tab). I think this may be at the LiveReload API/Protocol level, and it's "just the way it's designed".

In my use-case, the file/end-point that I type in the address bar, is a reference to a real file, but the response contains additional generated information, without any changes to the real file itself.

An example:

• browser hits README.md
• server gets the request
• server reads the README file and generates and HTML response object
• server reads the README file for includes and finds<!--include|readme2.md-->
• server fetches readme2.md, and generates HTML response
• server inserts readme2.md into the HTML response for README.md
• server sends back the combined HTML response object for the 2 files
• browser renders the combined README documents
• LiveReload listens...
• user updates readme2.md

LiveReload has no way of knowing about readme2.md. If I added that file to the watch list, wouldn't LiveReload ignore it anyway, as it is not in the current page's resource list?

I guess this is probably going way beyond what LiveReload is intended for, and I should just write a Chrome extension to reload the page.

[napcs]

Yeah this is the tricky thing about this. LiveReload works by injecting the JS on the page, or by having the browser extension do it. So it can only load that page.

You might want to look at using browser-sync and its proxy feature. Perhaps that'd work for what you want to do - you could set up your server to watch for changes and regenerate your readme file, and then point browser-sync to that other server using its proxy option. I do this for Rails and PHP app servers a lot.

[F1LT3R]

Good thoughts, thank you. I did try BrowserSync with Proxy as soon as I bumped into this issue a few days ago. I found that the BrowserSync Reload command was a) slow, and b) noisy (the browser sync growl would pop up each time there was a reload). Perhaps I am doing it wrong. I was using chokidar to watch and BrowserSync to reload (before finding out that bs had watch). There may be a way to tell browser sync not to be so noisy, and a way to speed up the proxy; failing that, I may just have to write a browser extension.

I wanted to avoid "yet-another-x" and going with an existing paradigm, but I'm having trouble finding one that really fits. Anyway, thanks so much for the response, it's good to get a sense that I was trying some of the right things from someone who's immersed in LiveReload.

[F1LT3R]

Actually for the sake of anyone else reading this, the following will stop the notification:

bs.init({notify: false});