Reviewed-on: #59
Reviewed-by: kosssi <simon@p4pillon.org>
Les noms utilisés dans le template par défaut lors d'une création d'un ticket de Bug étaient les "anciens" noms (Cargo, Tauri ...)
Cette PR :
- Ajoute quelques options (docs, scripts ...)
- Remplace les anciens noms par des labels plus compréhensifs et les noms des "crates" ou dossiers correspondant
# Détails
Implémente (en partie) les "bonnes pratiques" de gestion des erreurs Rust décrites dans le ticket #34
Cette PR se concentre beaucoup sur la gestion des erreurs "internes" et peu sur la manière dont on les expose à l'extérieur (API) ou les trace (dans des logs ou sur une app de suivi de logs). Une deuxième phase de travail sera nécessaire pour cela.
De même, les choix faits à de nombreux endroits sont très perfectibles :
- les noms des erreurs et enums ne semblent pas toujours au top
- certains "fallback" pourraient sans doute être améliorés
- certaines erreurs pourraient peut-être remonter + de contexte
- l'usage des librairies d'aide (anyhow et thiserror) ne sont pas uniformes
Cela dit, il est difficile de vraiment affiner ces éléments sans être dans des situations concrètes et réalistes. Je pense donc que c'est à force d'itération, en situation concrète et au fur et à mesure des relectures de code en DA que nous améliorerons ces points.
# Pourquoi ?
La gestion des erreurs en Rust est extrêmement puissante, permettant de construire des infrastructures où les "bugs" inattendus sont quasiment inexistants. Pour cela, un certain nombre de bonnes pratiques sont à suivre dans la gestion des retours d'erreurs des fonctions et des programmes à plus haut niveau.
# Documentation
CF #34
Reviewed-on: #52
Reviewed-by: theo <theo.lettermann@gmail.com>
Reviewed-by: kosssi <simon@p4pillon.org>
### Détails
Changement de `askama::Template` à `askama_axum::Template`.
### Pourquoi ?
Pour supprimer les `into_response()` et ainsi réduire les imports
### Documentation
https://djc.github.io/askama/integrations.html#axum-integration
Reviewed-on: #51
Reviewed-by: florian_briand <florian.briand@digital-engine.info>
### 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](6bd6556385/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
Reviewed-on: #47
Reviewed-by: florian_briand <florian.briand@digital-engine.info>
### Détails
`fmt` permet de formater le code Rust, je pense que c'est une bonne chose que l'on utilise l'utilitaire aevc la commande `cargo fmt` nous pourrons mettre en place un test de validation des DAs quand nous aurons une CI avec la commande suivante `cargo fmt --all -- --check`.
### Pourquoi ?
Pour rendre le code plus lisible
### Documentation
https://rust-lang.github.io/rustfmt/
Reviewed-on: #48
Reviewed-by: theo <theo.lettermann@gmail.com>
Cette PR explore une organisation en "pages" pour le rendu des différents "onglets" de la navbar.
Contrairement à la PR précédente (#40), les composants ajoutés viennent de la bibliothèque Flowbite
En plus des pages, cette PR :
- remplace le texte de chargement Chargement... par des skeleton (sorte de placeholder visuels)
- utilise le système HTMX de hx-swap-oob pour changer le titre dynamiquement
- ajoutent les fichiers minifiés de de htmx / alpinejs / flowbite dans les assets, avec leur numéro de version
Reviewed-on: #42
Reviewed-by: kosssi <simon@p4pillon.org>
Reviewed-by: theo <theo.lettermann@gmail.com>
Cette PR met concrètement en place une première interface combinant les technologies front choisies pour le projet.
- Setup de tailwindcss (+ documentation basique sur son usage)
- Implémentation d'un composant "complexe" de barre de navigation
- Gestion du responsive
- Combinaison de Askama (Jinja) + HTMX
- Usage de AlpineJS pour les micro-interactions (affichage des menus)
À suivre, dans la PR #42 : une interface moins "random" et plus orientée vers nos besoins
Contribue à #8
Reviewed-on: #40
Reviewed-by: kosssi <simon@p4pillon.org>
Reviewed-by: theo <theo.lettermann@gmail.com>
### Détails
Spécifie la version de Tauri à installer dans la documentation
### Pourquoi ?
Il faut la bonne version de Tauri pour que ça fonctionne et que l'on soit raccord dans l'équipe
Reviewed-on: #41
Reviewed-by: florian_briand <florian.briand@digital-engine.info>
