- Introduction de nouveaux mécanismes
- Réecriture de l'evaluation et du parsing des règles.
- Les règles peuvent apparaître dans les formules de calcul
- Introduction d'un AST en bonne et due forme
- Réecriture de buildRuleDependancies.
- Ajout d'une passe pour la désambiguation des références
- Réecriture de rendNonApplicable et de remplace
- Réimplémentation de parentDependancy
Voir #1191
* 🤖 Utilisation du CI de GitHub pour le déploiement Netlify
* 🤖 Personnalise le message de déploiement
* 🤖 Renomme les variables d'environnement Netlify
La fonction `uniroot` prend 2 paramètres d'amorçage "min" et "max" qui
nous définissions jusqu'alors comme des minimums et maximum absolus
-10^8 et +10^8. Vu que nous sommes obligés de calculer au moins une
première valeur à l'extérieur de `uniroot` notamment pour calculer les
variables manquantes, ce commit permet de ré-utiliser ce calcul dans
l'amorçage d' `uniroot`.
Les gains de performances sont détaillés dans la PR associée.
Par ailleurs supprime l'option "valeurs négatives possibles" rendue
obsolète.
Il y a des légers décalages d'1€ sur une dizaine de snapshots qui liés à
des arrondis à l'euro. On calcule en effet les inversions à 10 centimes
près et on peut donc tomber sur une valeur de xx,54€ là où la vraie
valeur est xx,48€ ce qui donne 1€ de différence avec l'arrondi alors que
la différence initialement calculée est inférieure à 10 centimes.
Par curiosité j'ai rejoué les tests de non-régressions en changeant les
paramètres d'`uniroot` pour avoir une précision au centime près (en
augmentant le nombre max d'itération à 50) et il se trouve que sur la
dizaine de tests différents entre ce commit et la version d'avant une
moitié des arrondis à l'euro étaient faux avant et corrects maintenant
et inversement pour l'autre moitié.
L'aide est compliquée à implémenter car elle nécessite de demander le CA
mois par mois. On pourrait faire un simulateur dédié (une utilisation
pour les variables temporelles ?), mais en attendant on se contente de
référencer la page Urssaf quand on est sur le simulateur AE.
Utilisation d'un fork en attendant que React 17 soit supporté par
Enzyme.
J'ai essayé rapidement la librairie
https://testing-library.com/docs/react-testing-library/migrate-from-enzyme
vers laquelle certains utilisateurs d'Enzyme semblent maintenant se
tourner, mais la migration est non triviale (alors même que nous n'avons
qu'un seul fichier qui utilise les tests Enzyme !)
Plein de nouveautés et notamment la possibilité de "programmer" les
types chaînes littérales qui nous sera utile par exemple pour vérifier
statiquement la validité d'une *expression* publicode dans
`engine.evaluate`.
https://devblogs.microsoft.com/typescript/announcing-typescript-4-1/
⬆ MAJ ESLint-typescript pour la compatibilité
En analysant les traces d'execution, il apparaît qu'un temps conséquent
est passé dans la fonction `evaluateApplicability`. L'ajout d'un cache
simple semble améliorer significativement les performances (environ -30%
dans mes mesures non scientifiques).
Suite à la migration vers SendInBlue.
Je n'ai pas trouvé d'API documentée sur la manière de créer son propre
formulaire, donc j'ai simplement repris l'URL POST de l'iframe proposée
(ce que l'on faisait déjà avec MailChimp me semble-t-il).
- évite l'indirection vers "parseReferenceTransforms" pour les
références simples (il faut encore simplifier ce code)
- déplacement de fonctions de parsage vers les "stateless"
- typage de registerEvaluationFunction
- simplifie fragments.join()
Johan Girod
Maxime Quandalle
Maxime Quandalle
Mael
Alexandre Hajjar
Johan Girod