Utilisation de Valinor pour le générateur de tech letter#1739
Utilisation de Valinor pour le générateur de tech letter#1739Mopolo merged 1 commit intoafup:masterfrom
Conversation
f086515 to
c2d8a22
Compare
| return (new MapperBuilder()) | ||
| ->supportDateFormats('!Y-m-d') | ||
| ->mapper() | ||
| ->map(TechLetter::class, Source::json($json)); |
There was a problem hiding this comment.
ce n'est pas un peu trop magique ? il ne faudrait pas explicitement indiquer dans le map ce qu'on mappe pour être plus clair/explicite/maintenable/éviter la magie ?
There was a problem hiding this comment.
Alors oui c'est forcément plus "magique" un auto-mapper que de le faire à la main.
C'est totalement subjectif comme préférence j'avoue.
Mais selon moi :
Ce qui se mappe là il suffit d'aller voir les objets, puisqu'au final dans la majorité des cas c'est ça qui compte et pas la source.
Valinor c'est aussi un mapper très strict en terme de typage, ce qui est une bonne chose (et il y a des options pour ouvrir un peu de souplesse quand c'est nécessaire).
Ce côté strict ça permet d'attraper des erreurs qu'on gère rarement avec le mapping manuel (par exemple une string vide transformée en 0, un booléen chelou, etc). Ce genre d'erreur ça peut amener à la création d'un objet incorrect qui va déclencher des erreurs parfois beaucoup plus loin dans le code.
C'est performant (et ça le sera encore plus quand on sera en PHP 8).
Et on s'en sert déjà pour le crawling de meetup, pour Bluesky et sur Planete PHP.
Un outil comme ça, je trouve, aide à détecter quand une source change de format grâce aux erreurs qui sont plus claires que des erreurs plus classiques de clef de tableau manquantes ou autres erreurs natives.
Tout ça couplé au test unitaire (qui n'existait pas et a révélé 2/3 soucis) je trouve ça plus clair.
Bien sûr je vais pas imposer donc si tu penses que ça ne vaut pas le coup je suis prêt à en discuter.
c2d8a22 to
f19bca3
Compare
No description provided.