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
6 changed files with 1537 additions and 50 deletions

5
.ignore Normal file
View File

@ -0,0 +1,5 @@
# Ignorer les fichiers dont ne dépent pas la compilation
*.md
tailwind.config.js
*.example
scripts

1487
Cargo.lock generated

File diff suppressed because it is too large Load Diff

View File

@ -47,6 +47,19 @@ Si vous souhaitez lancer les composants séparément, les indications de lanceme
- [app](crates/app/README.md)
- [sesam-vitale](crates/sesam-vitale/README.md)
## Rechargement automatique
Pour permettre de développer plus rapidement, il existe une librairie qui recompile automatiquement nos modifications en cours : [`cargo-watch`](https://github.com/watchexec/cargo-watch) permet de relancer une commande `cargo` lorsqu'un fichier est modifié (example: `cargo run` --> `cargo watch -x run`).
Voici la commande pour l'installer dans un _package_ :
```bash
cargo add cargo-watch --dev --package app
```
Le fichier [`.ignore`](./ignore) permet d'ignorer certains fichiers pour éviter de relancer la recompilation inutilement.
⚠️ La librairie n'est pas compatible avec _Windows 7_ et les versions antérieurs de _Windows_.
## Build
Packager le client desktop

View File

@ -7,7 +7,13 @@ edition = "2021"
askama = "0.12.1"
askama_axum = "0.4.0"
axum = "0.7.5"
listenfd = "1.0.1"
notify = "6.1.1"
serde = { version = "1.0.204", features = ["derive"] }
tokio = { version = "1.39.1", features = ["macros", "rt-multi-thread"] }
tower-http = { version = "0.5.2", features = ["fs"] }
tower-livereload = "0.9.3"
[dev-dependencies]
cargo-watch = "8.5.1"
systemfd = "0.4.0"

View File

@ -13,3 +13,23 @@
```bash
cargo run --bin app
```
## Rechargement automatique (_auto-reload_)
Pour le projet `app`, nous utilisons en plus de `cargo-watch` ses librairies :
- [`systemfd`](https://github.com/mitsuhiko/systemfd) permet de redémarrer un serveur sans interrompre les connexions en cours, il transmet le descripteur de fichier du socket à une nouvelle instance du serveur (exemple: `cargo watch -x run` --> `systemfd --no-pid -s http::3000 -- cargo watch -x run`). Si le port est déjà pris il en prendra un autre.
- [`listenfd`](https://github.com/mitsuhiko/listenfd) permet, côté _Rust_, de démarrer un serveur en utilisant des connexions déjà ouvertes.
Pour notre application voici la commande à lancer :
```bash
systemfd --no-pid -s http::3000 -- cargo watch -x 'run --bin app'
```
## Chargement à chaud (_livereload_)
Pour que notre navigateur rafraîchisse automatique notre page lorsque le serveur a été recompilé, nous utilisons la librairie [`tower-livereload`](https://github.com/leotaku/tower-livereload).
A chaque changement, que ça soit sur du code en _Rust_, _HTML_, _CSS_ ou _JS_ alors le navigateur va recharger entièrement la page.
En Rust, il n'existe pas encore d'outil de _Hot Reload_ complet et intégré comme on en trouve dans d'autres environnements de développement web, comme pour _Node.js_.

View File

@ -1,17 +1,63 @@
use ::app::get_router;
use axum::body::Body;
use axum::http::Request;
use listenfd::ListenFd;
use notify::Watcher;
use std::env;
use std::path::Path;
use tokio::net::TcpListener;
use tower_livereload::predicate::Predicate;
use tower_livereload::LiveReloadLayer;
kosssi marked this conversation as resolved Outdated

Ç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)

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 ;)

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)).
/// 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
#[derive(Copy, Clone)]
struct NotHtmxPredicate;
impl<T> Predicate<Request<T>> for NotHtmxPredicate {
fn check(&mut self, req: &Request<T>) -> bool {
!(req.headers().contains_key("hx-request"))
}
}
const DEFAULT_LISTENER: &str = "localhost:3000";
async fn get_tcp_listener() -> TcpListener {
kosssi marked this conversation as resolved Outdated

Ç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)); ```

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

Du coup je laisse pour l'instant `fmt` formater comme il veut ;)
let mut listenfd = ListenFd::from_env();
match listenfd.take_tcp_listener(0).unwrap() {
kosssi marked this conversation as resolved Outdated

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

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.
// 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(DEFAULT_LISTENER).await.unwrap(),
}
}
fn get_livereload_layer(templates_path: &Path) -> LiveReloadLayer<NotHtmxPredicate> {
kosssi marked this conversation as resolved Outdated

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

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 mut watcher = notify::recommended_watcher(move |_| reloader.reload()).unwrap();
watcher
.watch(templates_path, notify::RecursiveMode::Recursive)
.unwrap();
livereload.request_predicate::<Body, NotHtmxPredicate>(NotHtmxPredicate)
}
#[tokio::main]
async fn main() {
let manifest_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
let assets_path = Path::new(&manifest_dir).join("assets");
let router = get_router(assets_path.as_path());
let templates_path = Path::new(&manifest_dir).join("templates");
// TODO: select port based on available port (or ask in CLI)
let listener = tokio::net::TcpListener::bind("localhost:3000")
let livereload_layer = get_livereload_layer(&templates_path);
let router = get_router(assets_path.as_path()).layer(livereload_layer);
let listener: TcpListener = get_tcp_listener().await;
println!("Listening on: http://{}", listener.local_addr().unwrap());
// Run the server with the router
axum::serve(listener, router.into_make_service())
.await
.unwrap();
println!("Listening on: http://{}", listener.local_addr().unwrap());
axum::serve(listener, router).await.unwrap();
}