[WIP] Hot reloading

[Swoorup]

Awesome project btw. I kinda started on #920 and wanted your input.

• Semi working hot reloading without unsafe.
• Need to also attach the tower-livereload to make it fully automated.

It looks like the tera member in the TeraView struct needs to be made private, to not expose the leaky details about it being either in a Mutex in debug vs not wrapped in release builds.

Perhaps we could add 2 methods,

• fn with_tera<'s, A>(&'s mut self, f: impl FnOnce(&'s tera::Tera) -> A ) -> A
• fn with_tera_mut<'s, A>(&'s mut self, f: impl FnOnce(&'s mut tera::Tera) -> A ) -> A

Bit also unsure about wiring up the tower-livereload without breaking existing interfaces. I did a roughed up patching within my own code and it works without issues.

[jondot]

Hi! happy you decided to contribute!

I'm wondering if we can split this into:

• reloading content from disk
• live-reload (triggering browser refresh) -- which will probably be solved by some kind of middleware glue which some people will want to opt-in and opt-out

There is a good chance a simplification can be made for reloading from disk - by just reading a file, and then rendering using a template string (instead of arc/mutex/ etc.). It can make a simpler (yet less clever) code, since we don't much care about perf in debug builds. WDYT?

[jondot]

Moving this one to 0.14, if you can refactor it into a middleware that only does live-reload that would be perfect!

[Swoorup]

Just back from holidays, I'll try to see if I can come up with something simpler this or next week. Think most of the reload logic could probably live in the user side, if we somehow expose methods like full_reload and paths in the TeraView

[kaplanelad]

@Swoorup @jondot,

I have a few notes regarding this PR, live reload functionality, and some related feedback from my app.
Here's the bottom line: I believe this feature should be gated behind a feature flag

First (not actually relevant for this PR, but relevant to hot reload)
In the Initializer view engine, there are two separate logic flows for registering functions into Terra.
Refer to this line.

Currently, if I want to register additional functions or filters, I need to implement them in two different places. This is not intuitive and can lead to problem in release (and the test should to catch this problem). If this was done solely for hot reload support, I think we should consider a different approach for its implementation.

About this PR:
Hot reload functionality is relevant only during development. As part of our effort to minimize dependencies and reduce compilation time, the following crates should not be included in release builds:

notify-debouncer-full = { version = "0.4.0" }
tower-livereload = { version = "0.9.4" }

And regarding #[cfg(debug_assertions)]
Using #[cfg(debug_assertions)] introduces issues in tests because it leads to behavior that differs between development and production builds. Here's an example test that fails due to this discrepancy:

pub fn test() -> String {
    #[cfg(debug_assertions)]
    let res = "#[cfg(debug_assertions)]";
    #[cfg(not(debug_assertions))]
    let res = "#[cfg(not(debug_assertions))]";

    res.to_string()
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_debug_assertions() {
        assert_eq!(test(), "#[cfg(not(debug_assertions))]");
    }
}

[kaplanelad]

We now reload content from disk.