Configurer le re-build automatique de l'app front lors de changements #47
No reviewers
Labels
No Label
bug
duplicate
enhancement
help wanted
independant
invalid
module/autre
module/backend
module/desktop
module/docs
module/frontend
module/scripts
module/sesam-vitale
module/utils
open-source
question
to-triage
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: P4Pillon/Krys4lide#47
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "html_auto_reload"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Détails
Nous avons plusieurs besoins :
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
main.rs
Fix #44
2eba7c5e10
toc342d922a7
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!
Extrait de la doc de watch :
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
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 run
en cas de changements dans les fichiertower_livereload
lorsqu'ils changent@ -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)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 ;)
J'ai ajouté de la documentation :
@ -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 :
Du coup je laisse pour l'instant
fmt
formater comme il veut ;)@ -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 dossierassets/
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.
@ -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
Nous avons fait du pair-programming ce matin pour répondre à cette conversation d’où les 2 commits avec @florian_briand ;)
c342d922a7
to4d34215aa5
4d34215aa5
to9c57b119ce
@theo et @florian_briand j'ai ajouté un commit avec de la documentation.
J'essaye actuellement de rendre
main.rs
plus lisible ;)@ -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
dfdf0d3bae
tofb201f9d5d
WIP: Configurer le re-build automatique de l'app front lors de changementsto Configurer le re-build automatique de l'app front lors de changements