P4Pillon/Krys4lide
4
2
Fork 0
Code Issues 27 Pull Requests 3 Actions Packages Projects 1 Releases Activity

Configurer le re-build automatique de l'app front lors de changements #47

Merged
kosssi merged 7 commits from html_auto_reload into main 2024-08-09 15:50:54 +02:00
Conversation 5 Commits 7 Files Changed 6 +21 -16
1 changed files with 21 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit dcb4a7680e - Show all commits

37
crates/app/src/main.rs
View File

@ -7,40 +7,45 @@ use std::path::Path;
use tokio::net::TcpListener;
use tower_livereload::LiveReloadLayer;
// Nous filtrons les requêtes de `htmx` pour ne pas inclure le script _JS_ qui gère le rechargement
// Voir https://github.com/leotaku/tower-livereload/pull/3
/// Nous filtrons les requêtes de `htmx` pour ne pas inclure le script _JS_ qui gère le rechargement
kosssi marked this conversation as resolved Outdated
florian_briand commented 2024-08-08 12:12:16 +02:00
Outdated
Review
Copy Link

Ça vaudrait le coup de "comprendre" pourquoi on exclue les requêtes htmx dans ce contexte, et de l'expliquer en docstring de la fonction

(PS : les docstrings se font avec ### bla bla bla au dessus de la fonction)

Ça vaudrait le coup de "comprendre" pourquoi on exclue les requêtes htmx dans ce contexte, et de l'expliquer en docstring de la fonction (PS : les docstrings se font avec `### bla bla bla` au dessus de la fonction)
florian_briand commented 2024-08-08 12:30:44 +02:00
Outdated
Review
Copy Link

Le pourquoi du comment vient de cette issue dont le fix a été cette PR

En gros, c'est pour éviter que le script JS qui se gère du livereload côté client ne soit injecté dans chaque requête htmx ; car on n'en a besoin que sur la requête qui charge la page de "base".

Ça devrait donc, en effet, être approprié pour nous d'avoir ce mécanisme

PS : astuce, pour trouver cette info, j'ai cherché la ligne de code en question dans les PR github ;)

Le pourquoi du comment vient de cette [issue](https://github.com/leotaku/tower-livereload/issues/2) dont le fix a été cette [PR](https://github.com/leotaku/tower-livereload/pull/3) En gros, c'est pour éviter que le script JS qui se gère du livereload côté client ne soit injecté dans chaque requête htmx ; car on n'en a besoin que sur la requête qui charge la page de "base". Ça devrait donc, en effet, être approprié pour nous d'avoir ce mécanisme PS : astuce, pour trouver cette info, j'ai [cherché](https://github.com/search?q=%21req.headers%28%29.contains_key%28%22hx-request%22%29&type=pullrequests) la ligne de code en question dans les PR github ;)
👍 1
kosssi commented 2024-08-09 00:38:38 +02:00
Outdated
Review
Copy Link

J'ai ajouté de la documentation :

Nous filtrons les requêtes de htmx pour ne pas inclure le script JS qui gère le rechargement (Référence).

J'ai ajouté de la documentation : > Nous filtrons les requêtes de `htmx` pour ne pas inclure le script _JS_ qui gère le rechargement ([Référence](https://github.com/leotaku/tower-livereload/pull/3)).
/// Voir https://github.com/leotaku/tower-livereload/pull/3
fn not_htmx_predicate<T>(req: &Request<T>) -> bool {
!req.headers().contains_key("hx-request")
}
const DEFAULT_LISTENER: &str = "localhost:3000";
async fn get_tcp_listener() -> TcpListener {
let mut listenfd = ListenFd::from_env();
match listenfd.take_tcp_listener(0).unwrap() {
// if we are given a tcp listener on listen fd 0, we use that one
Some(listener) => {
listener.set_nonblocking(true).unwrap();
kosssi marked this conversation as resolved Outdated
florian_briand commented 2024-08-08 12:10:01 +02:00
Outdated
Review
Copy Link

Ça vaut le coup de passer à la ligne, quand y'a de la programmation "fonctionnelle" comme ça, à base de layers qui s'empilent :

let router = get_router(assets_path.as_path())
    .layer(livereload.request_predicate(not_htmx_predicate));
Ça vaut le coup de passer à la ligne, quand y'a de la programmation "fonctionnelle" comme ça, à base de layers qui s'empilent : ``` let router = get_router(assets_path.as_path()) .layer(livereload.request_predicate(not_htmx_predicate)); ```
kosssi commented 2024-08-09 00:36:56 +02:00
Outdated
Review
Copy Link

Du coup je laisse pour l'instant fmt formater comme il veut ;)

Du coup je laisse pour l'instant `fmt` formater comme il veut ;)
TcpListener::from_std(listener).unwrap()
}
// otherwise fall back to local listening
kosssi marked this conversation as resolved Outdated
florian_briand commented 2024-08-08 12:24:53 +02:00
Outdated
Review
Copy Link

Je pense qu'il faut également watch le dossier assets/ pour reload quand il y a des changements dans les fichiers ".js", ".css", etc.

cf https://github.com/leotaku/tower-livereload/blob/master/examples/axum-htmx/src/main.rs

Je pense qu'il faut également `watch` le dossier `assets/` pour reload quand il y a des changements dans les fichiers ".js", ".css", etc. cf https://github.com/leotaku/tower-livereload/blob/master/examples/axum-htmx/src/main.rs
kosssi commented 2024-08-09 00:45:01 +02:00
Outdated
Review
Copy Link

Actuellement lorsque je modifie un fichier CSS ça recharge la page. Je ne comprends pas vraiment pourquoi mais c'est bien le cas.

Actuellement lorsque je modifie un fichier _CSS_ ça recharge la page. Je ne comprends pas vraiment pourquoi mais c'est bien le cas.
None => TcpListener::bind(DEFAULT_LISTENER).await.unwrap(),
}
}
#[tokio::main]
async fn main() {
let manifest_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
let assets_path = Path::new(&manifest_dir).join("assets");
let templates_path = Path::new(&manifest_dir).join("templates");
// Setup the livereload
kosssi marked this conversation as resolved Outdated
florian_briand commented 2024-08-08 12:07:33 +02:00
Outdated
Review
Copy Link

Tout ce passage à base de listeners est un peu cryptique ; je pense que ça vaudrait le coup de le sortir dans une fonction au nom explicite pour gagner en lisibilité :) (get_tcp_listener par exemple)

Ça vaudrait le coup, aussi, de commenter l'objectif / la raison d'être des différents listeners et autre créés ici

Tout ce passage à base de listeners est un peu cryptique ; je pense que ça vaudrait le coup de le sortir dans une fonction au nom explicite pour gagner en lisibilité :) (`get_tcp_listener` par exemple) Ça vaudrait le coup, aussi, de commenter l'objectif / la raison d'être des différents listeners et autre créés ici
kosssi commented 2024-08-09 14:01:55 +02:00
Outdated
Review
Copy Link

Nous avons fait du pair-programming ce matin pour répondre à cette conversation d’où les 2 commits avec @florian_briand ;)

Nous avons fait du pair-programming ce matin pour répondre à cette conversation d’où les 2 commits avec @florian_briand ;)
let livereload = LiveReloadLayer::new();
let reloader = livereload.reloader();
let router =
get_router(assets_path.as_path()).layer(livereload.request_predicate(not_htmx_predicate));
let mut watcher = notify::recommended_watcher(move |_| reloader.reload()).unwrap();
watcher
.watch(&templates_path, notify::RecursiveMode::Recursive)
.unwrap();
let mut listenfd = ListenFd::from_env();
let listener = match listenfd.take_tcp_listener(0).unwrap() {
// if we are given a tcp listener on listen fd 0, we use that one
Some(listener) => {
listener.set_nonblocking(true).unwrap();
TcpListener::from_std(listener).unwrap()
}
// otherwise fall back to local listening
None => TcpListener::bind("localhost:3000").await.unwrap(),
};
let router =
get_router(assets_path.as_path()).layer(livereload.request_predicate(not_htmx_predicate));
let listener: TcpListener = get_tcp_listener().await;
println!("Listening on: http://{}", listener.local_addr().unwrap());
// Run the server with the router