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
Owner

Détails

Nous avons plusieurs besoins :

  • reconstruire le serveur lorsque des fichiers Rust ont été modifiés
  • recharger les fichiers HTML lors d'un changement directement dans le navigateur

Le fichier .ignore permet d'indiquer à systemfd de ne pas surveiller l'état de ses fichiers.

Actuellement lors d'une modification, on se retrouve sur la page d'accueil vu que l'url reste toujours la même lors d'un changement de page.

Pourquoi ?

Pour être plus rapide lors du développement et ainsi ne pas à avoir à relancer les commandes trop régulièrement.

Documentation

Documentation des librairies

Todo

  • Documenter un peu plus
  • Rendre plus lisible main.rs

Fix #44

### Détails Nous avons plusieurs besoins : - reconstruire le serveur lorsque des fichiers _Rust_ ont été modifiés - recharger les fichiers HTML lors d'un changement directement dans le navigateur Le fichier `.ignore` permet d'indiquer à `systemfd` de ne pas surveiller l'état de ses fichiers. Actuellement lors d'une modification, on se retrouve sur la page d'accueil vu que l'url reste toujours la même lors d'un changement de page. ### Pourquoi ? Pour être plus rapide lors du développement et ainsi ne pas à avoir à relancer les commandes trop régulièrement. ### Documentation Documentation des librairies - [auto-reload sur Axum](https://github.com/tokio-rs/axum/blob/6bd6556385c7f6bf1ee7ea64e3a8fbe2076a1506/examples/auto-reload/README.md) - [tower_livereload](https://docs.rs/tower-livereload/latest/tower_livereload/) ### Todo - [x] Documenter un peu plus - [x] Rendre plus lisible `main.rs` Fix #44
kosssi added 2 commits 2024-08-08 00:30:06 +02:00
kosssi requested review from julien.misiak 2024-08-08 00:30:40 +02:00
kosssi requested review from theo 2024-08-08 00:30:40 +02:00
kosssi requested review from florian_briand 2024-08-08 00:30:40 +02:00
kosssi added the
enhancement
label 2024-08-08 00:30:46 +02:00
kosssi force-pushed html_auto_reload from 2eba7c5e10 to c342d922a7 2024-08-08 00:43:36 +02:00 Compare
Owner

Je me réveille donc je met pas trop les formes mais voilà mes questions:
A quoi sert listenfd si axum serve deja les fichier et cargo watch permet d'observer le file system? Ca serait possible avec seulement cargo watch?

Le .ignore est il nécessaire ?

Sinon top!

Je me réveille donc je met pas trop les formes mais voilà mes questions: A quoi sert listenfd si axum serve deja les fichier et cargo watch permet d'observer le file system? Ca serait possible avec seulement cargo watch? Le .ignore est il nécessaire ? Sinon top!

A quoi sert listenfd si axum serve deja les fichier et cargo watch permet d'observer le file system? Ca serait possible avec seulement cargo watch?

Extrait de la doc de watch :

Cargo Watch pairs very well with systemfd/Catflap, tools for Unixy platforms that lets one spawn a socket before the watcher runs that Rust servers can then bind to, avoiding request-dropping and the infamous ADDRINUSE error.
> A quoi sert listenfd si axum serve deja les fichier et cargo watch permet d'observer le file system? Ca serait possible avec seulement cargo watch? Extrait de la [doc de watch](https://github.com/watchexec/cargo-watch?tab=readme-ov-file#reloading-servers-seamlessly) : ``` Cargo Watch pairs very well with systemfd/Catflap, tools for Unixy platforms that lets one spawn a socket before the watcher runs that Rust servers can then bind to, avoiding request-dropping and the infamous ADDRINUSE error. ```

Cargo watch ne supporte pas Windows 7 et inférieur

Est-ce qu'on considère ça comme ok ou est-ce un problème ?
Le cas échéant, ça mérite d'être documenté dans le README

Cargo watch [ne supporte pas Windows 7 et inférieur](https://github.com/watchexec/cargo-watch/issues/69) Est-ce qu'on considère ça comme ok ou est-ce un problème ? Le cas échéant, ça mérite d'être documenté dans le README

De mon côté, j'ai du mal à comprendre l'utilité des différents systèmes de reload. Je détaille pour essayer de bien comprendre :)

  • cargo watch : relance le cargo run en cas de changements dans les fichier
  • systemfd : transfert les requêtes de l'ancien process au nouveau process lors d'un reload par cargo watch
  • tower_livereload : permet de déclencher un rechargement automatique de la page dans le navigateur
  • notify::Watcher : permet de surveiller des fichiers ... pour déclencher tower_livereload lorsqu'ils changent
De mon côté, j'ai du mal à comprendre l'utilité des différents systèmes de reload. Je détaille pour essayer de bien comprendre :) - cargo watch : relance le `cargo run` en cas de changements dans les fichier - systemfd : transfert les requêtes de l'ancien process au nouveau process lors d'un reload par cargo watch - tower_livereload : permet de déclencher un rechargement automatique de la page dans le navigateur - notify::Watcher : permet de surveiller des fichiers ... pour déclencher `tower_livereload` lorsqu'ils changent
florian_briand requested changes 2024-08-08 12:30:54 +02:00
Dismissed
@ -4,0 +7,4 @@
use tokio::net::TcpListener;
use tower_livereload::LiveReloadLayer;
fn not_htmx_predicate<T>(req: &Request<T>) -> bool {

Ç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 ;)
Author
Owner

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)).
kosssi marked this conversation as resolved
@ -10,0 +20,4 @@
let livereload = LiveReloadLayer::new();
let reloader = livereload.reloader();
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));
Ç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)); ```
Author
Owner

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

Du coup je laisse pour l'instant `fmt` formater comme il veut ;)
kosssi marked this conversation as resolved
@ -10,0 +23,4 @@
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();

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
Author
Owner

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.
kosssi marked this conversation as resolved
@ -10,0 +34,4 @@
}
// otherwise fall back to local listening
None => TcpListener::bind("localhost:3000").await.unwrap(),
};

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
Author
Owner

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 ;)
kosssi marked this conversation as resolved
kosssi force-pushed html_auto_reload from c342d922a7 to 4d34215aa5 2024-08-08 23:42:42 +02:00 Compare
kosssi force-pushed html_auto_reload from 4d34215aa5 to 9c57b119ce 2024-08-09 00:35:42 +02:00 Compare
Author
Owner

@theo et @florian_briand j'ai ajouté un commit avec de la documentation.

J'essaye actuellement de rendre main.rs plus lisible ;)

@theo et @florian_briand j'ai ajouté un commit avec de la documentation. J'essaye actuellement de rendre `main.rs` plus lisible ;)
florian_briand reviewed 2024-08-09 00:46:58 +02:00
@ -16,0 +37,4 @@
A chaque changement, que ça soit sur du code en _Rust_, _HTML_, _CSS_ ou _JS_ alors le navigateur va recharger entièrement la page.
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)).

Je ne suis pas fan de ce genre de documentation "séparée" qui évoque des détails d'implémentation : on est sûr que dès qu'on va toucher à l'implementation, on oubliera de mettre à jour ce readme, et paf, ça devient le bordel.

Donc en dehors des commandes d'install / build / run, des pré-requis / limitations à connaître absolument, des troubleshoot haut niveau et de ce genre de trucs, la doc mérite d'être, pour moi, dans le code, au niveau des fonctions ou modules concernés

Je ne suis pas fan de ce genre de documentation "séparée" qui évoque des détails d'implémentation : on est sûr que dès qu'on va toucher à l'implementation, on oubliera de mettre à jour ce readme, et paf, ça devient le bordel. Donc en dehors des commandes d'install / build / run, des pré-requis / limitations à connaître absolument, des troubleshoot haut niveau et de ce genre de trucs, la doc mérite d'être, pour moi, dans le code, au niveau des fonctions ou modules concernés
kosssi marked this conversation as resolved
kosssi added 1 commit 2024-08-09 01:30:16 +02:00
cargo add cargo-watch --dev --package app
cargo add systemfd --dev --package app
kosssi added 1 commit 2024-08-09 01:41:08 +02:00
florian_briand added 2 commits 2024-08-09 12:55:32 +02:00
florian_briand added 1 commit 2024-08-09 13:00:11 +02:00
kosssi force-pushed html_auto_reload from dfdf0d3bae to fb201f9d5d 2024-08-09 13:58:18 +02:00 Compare
kosssi changed title from WIP: Configurer le re-build automatique de l'app front lors de changements to Configurer le re-build automatique de l'app front lors de changements 2024-08-09 14:02:07 +02:00
kosssi requested review from florian_briand 2024-08-09 15:33:45 +02:00
florian_briand approved these changes 2024-08-09 15:49:05 +02:00
kosssi merged commit 69a2d11501 into main 2024-08-09 15:50:54 +02:00
kosssi deleted branch html_auto_reload 2024-08-09 15:50:54 +02:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: P4Pillon/Krys4lide#47
No description provided.