Configurer le re-build automatique de l'app front lors de changements #47
13
README.md
13
README.md
@ -47,6 +47,19 @@ Si vous souhaitez lancer les composants séparément, les indications de lanceme
|
|||||||
- [app](crates/app/README.md)
|
- [app](crates/app/README.md)
|
||||||
- [sesam-vitale](crates/sesam-vitale/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`).
|
||||||
|
|
||||||
|
La librairie ne fait pas partie des dépendances du projet, il faut donc l'installer avec la commande suivante :
|
||||||
|
```bash
|
||||||
|
cargo install cargo-watch
|
||||||
|
```
|
||||||
|
|
||||||
|
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
|
## Build
|
||||||
|
|
||||||
Packager le client desktop
|
Packager le client desktop
|
||||||
|
@ -14,16 +14,29 @@
|
|||||||
cargo run --bin app
|
cargo run --bin app
|
||||||
```
|
```
|
||||||
|
|
||||||
## L'auto-reload
|
## Rechargement automatique (_auto-reload_)
|
||||||
|
|
||||||
Pour permettre au projet de s'auto-recharger lors du développement, nous avons besoin de 2 librairies :
|
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.
|
||||||
|
|
||||||
|
La librairie `systemfd` ne fait pas partie des dépendances du projet, il faut donc l'installer avec la commande suivante :
|
||||||
```bash
|
```bash
|
||||||
cargo install cargo-watch systemfd
|
cargo install systemfd
|
||||||
```
|
```
|
||||||
|
|
||||||
Pour recompiler automatiquement le serveur lors de changement :
|
Pour notre application voici la commande à lancer :
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
systemfd --no-pid -s http::3000 -- cargo watch -x 'run --bin app'
|
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.
|
||||||
|
|
||||||
|
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
Outdated
|
|||||||
|
|
||||||
|
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_.
|
||||||
|
Loading…
Reference in New Issue
Block a user
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