[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