Closed NV closed 13 years ago
Livereload wasn't around when I was doing it, but I have written code where css rules were read in and acted on by javascript.
Someone making a web-based css editor or analyser would want this.
Of course this case might not be common enough to justify keeping the feature.
Would it be possible to make it more generic? config.apply_live_exts = ['css', 'js']
I see your case, but it seems rare to me.
I like the generic approach. However, there is a problem: when LR will support new extensions then they won't be applied live by default. LiveReload will reload images in the next version and I would like to do it live by default.
It makes sense to invert the logic, e.g.:
config.dont_apply_live = ['js']
Yep, I think config.dont_apply_live
is great solution.
So that livereload can help people deal with lots of weird edge-case uses, without polluting its code with exceptions, we could expose some hooks where users can add their own rules.
A user could then disable live css reloading where they need to like so: config.apply_live_filter = proc do |url, file, extension| return ext=="css" if url===/weird_page.html$/ true end
And there would be a corresponding config.reload_filter
or similar. An even more flexible and generic system could have the user specify a proc which returns :reload
, :apply_live
depending on what action should be taken or nil
to do nothing.
Something like this: config.action_filter = proc do |url, file, ext, default| case url when /weird_page.html$/ if %w[css js].include? ext :reload else :apply_live end when /\/admin\/.*/ (ext=="js")? :apply_live : :reload else
# fall back to the default provided by livereload's
# more simple huesistics:
default
end
end
The proc is provided with the url of the livereload enabled window, the file that has changed and its extension (for convenience) and what livereload's default behaviour would be.
This would enable people to fix issues like #53 for themselves.
I'm going to remove apply_css_live option from a
.livereload
config file. appply_css_live works so smooth. I don't see the reason to disable it.Is there someone who turns it off? If so, why?
It brings unnecessary complexity to the code and makes harder to implement things like #53.