Dynamic rendering mode #324

Kijewski · 2025-01-28T01:39:11Z

No description provided.

Kijewski · 2025-01-28T19:53:49Z

I started the PR before #255, that's why there is a conflict.

Could you have a first cursory look if you like the idea, @GuillaumeGomez? IMHO that could be a killer-feature. :)

How to use:

Run the axum-example: cargo r
Don't stop the process!
Open http://127.0.0.1:8080/
Change the background color to red.
Recompile (in a new tab): cargo b
Hit F5.

Runtime values most likely won't work, because I don't know how to serialize them.

GuillaumeGomez · 2025-01-28T19:56:08Z

What's this feature about btw?

Kijewski · 2025-01-28T19:59:45Z

Live-updating the templates, one of the most requested unimplemented features in askama: askama-rs/askama-old#491. (Instead of manually compiling, something like cargo watch should be used.)

GuillaumeGomez · 2025-01-28T20:01:16Z

😮

Wow. Ok, let me get through it.

GuillaumeGomez · 2025-01-28T20:09:14Z

rinja/src/dynamic/child.rs

+
+use super::{DYNAMIC_ENVIRON_KEY, MainRequest, MainResponse, Outcome};
+
+const PROCESSORS: usize = 4;


Any reason why four?

No. :) Maybe the processor count would be better?

Why do we need multiple processors?

Without it the templates are rendered one after another.

On my not-so-recent AMD Ryzen 7 2700X system, with four workers and in release mode, the rendering takes about the same time in dynamic mode as non-dynamic: 68µs vs 65µs in he axum example.

I see, another code comment. :D

GuillaumeGomez · 2025-01-28T20:09:45Z

rinja/src/dynamic/child.rs

+
+    let mut entries: Vec<_> = DYNAMIC_TEMPLATES.iter().map(|entry| entry.name()).collect();
+    entries.sort_unstable();
+    eprintln!("templates implemented by subprocess: {entries:?}");


println! instead maybe? It's not an error after all.

STDIN & STDOUT are reserved for communication with the parent process.

Sounds like a code comment is needed. :)

Yeah, possibly even a small UML'like actor diagram.

GuillaumeGomez · 2025-01-28T20:09:50Z

rinja/src/dynamic/child.rs

+    for window in entries.windows(2) {
+        if let &[a, b] = window {
+            if a == b {
+                eprintln!("duplicated dynamic template {a:?}");


GuillaumeGomez · 2025-01-28T20:11:49Z

rinja/src/dynamic/child.rs

+
+        let is_done = {
+            let mut stdout = stdout.lock().await;
+            stdout.write_all(line).await.is_err() || stdout.flush().await.is_err()


For it to be done, it needs to return an error? Seems a bit strange. At the very least, a code comment would be appreciated here.

If the connection to the parent process was interrupted, the child process can exit. Severing the connection is the first step in killing a subprocess.

Kijewski · 2025-01-28T20:12:15Z

rinja/Cargo.toml

+linkme = { version = "0.3.31", optional = true }
+notify = { version = "8.0.0", optional = true }
+parking_lot = { version = "0.12.3", optional = true, features = ["arc_lock", "send_guard"] }
+tokio = { version = "1.43.0", optional = true, features = ["macros", "io-std", "io-util", "process", "rt", "sync", "time"] }


linkme and notify are absolutely needed.

I tried to implement the PR without an async runtime, but well, tokio is just too well implemented to invent the wheel twice.

parking_lot could maybe be replace with an std::sync::Barrier of some sort. It's far from trivial, though.

GuillaumeGomez · 2025-01-28T20:21:00Z

I think I'll need more technical explanations. From what I can gather, we run a server watching files that then sends serialized JSON data to a client which re-renders the needed template files.

However, what are the clients/servers here exactly, how are they rebuilding templates is still something I cannot figure out. ^^'

rinja/src/dynamic/parent.rs

+        return Ok(ControlFlow::Continue(()));
+    }
+
+    let _ = values; // TODO


mathew-horner · 2025-06-05T23:44:19Z

This PR seems like massive overkill. If you change the template struct, you will need to recompile no matter what. If you just want to have changes to the template HTML file apply without recompilation, can't we just update the derived render function to use std::fs::read instead of include_bytes in debug builds?

Kijewski · 2025-06-06T00:17:04Z

If you just want to have changes to the template HTML file apply without recompilation, can't we just update the derived render function to use std::fs::read instead of include_bytes in debug builds?

The short explanation for the project reads

A template rendering engine based on Jinja, generating type-safe Rust code at compile time.

Do you see the problem?

Kijewski force-pushed the pr-dynamic-rendering branch 3 times, most recently from ad08c26 to edb222b Compare January 28, 2025 19:35

Kijewski changed the title ~~[WIP] Dynamic rendering mode~~ Dynamic rendering mode Jan 28, 2025

GuillaumeGomez reviewed Jan 28, 2025

View reviewed changes

Kijewski commented Jan 28, 2025

View reviewed changes

Kijewski force-pushed the pr-dynamic-rendering branch from edb222b to fc3ebeb Compare January 29, 2025 02:49

Kijewski mentioned this pull request Jan 29, 2025

Minor clean-ups #327

Merged

Kijewski force-pushed the pr-dynamic-rendering branch from fc3ebeb to cfd56ca Compare February 2, 2025 00:29

github-advanced-security bot found potential problems Feb 2, 2025

View reviewed changes

rinja/src/dynamic/parent.rs

return Ok(ControlFlow::Continue(()));

}

let _ = values; // TODO

Check notice

Code scanning / devskim

A "TODO" or similar was left in source code, possibly indicating incomplete functionality Note

Suspicious comment

Kijewski marked this pull request as draft February 2, 2025 00:30

Dynamic rendering mode

df17fc6

Kijewski force-pushed the pr-dynamic-rendering branch from cfd56ca to df17fc6 Compare February 2, 2025 00:37

Kijewski added the tbd in v0.13.1 label Feb 7, 2025

Kijewski removed the tbd in v0.13.1 label Apr 11, 2025


		use super::{DYNAMIC_ENVIRON_KEY, MainRequest, MainResponse, Outcome};

		const PROCESSORS: usize = 4;

Dynamic rendering mode #324

Are you sure you want to change the base?

Dynamic rendering mode #324

Uh oh!

Conversation

Kijewski commented Jan 28, 2025

Uh oh!

Kijewski commented Jan 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeGomez commented Jan 28, 2025

Uh oh!

Kijewski commented Jan 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeGomez commented Jan 28, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kijewski Jan 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GuillaumeGomez commented Jan 28, 2025

Uh oh!

Check notice

mathew-horner commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kijewski commented Jun 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Kijewski commented Jan 28, 2025 •

edited

Loading

Kijewski commented Jan 28, 2025 •

edited

Loading

Kijewski Jan 28, 2025 •

edited

Loading

mathew-horner commented Jun 5, 2025 •

edited

Loading