4 * plus rapide
- moins d'itérations max
- précision à 0.1€, n'est plus relative à l'objectif
- partage du cache entre les contrôles et les évaluations
- on évite de recalculer brut de base s'il a déjà été calculé par
inversion
Les variables qui n'ont pas de période définie ne subissent aucune
transformation.
Les variables flexibles ont la période courante de la simulation.
Est-ce nécessaire d'introduire ce 'période: flexible' ? C'est sûrement
possible de ne marquer flexibles que les variables d'entrée, et de le
déduire pour les variables de calcul, mais ça semble compliqué.
Ce n'est pas très propre, mais difficile de faire autrement sans revoir
l'architecture des filtres, du cache, des sélecteurs de la fiche de paie
et du l'explicaiton des cotisations...
Suppression des décorateurs.
Problème :
Les décorateurs que l'on utilisait correspondait à une ancienne
version de la proposal tc39, encore en stage 1 (voir 0). La
proposition a complètement évolué, pour ne plus du tout avoir
la même forme que précédement.
Au lieu de garder la version 'legacy', on choisit de se séparer
des décorateur, étant donné que le nouveau use case n'a plus rien
à voir, et que l'ancienne version peut être gérée de manière
quasi équivalente avec des fonctions et des compose
Ce ne sont pas des composants React, mais des fonctions.
A la base, il ne faudrait pas renvoyer des fonctions mais des
composants, il faudrait reprendre la fonction makeJsx de evaluation.js
C'est un hack pour palier à nos problèmes de performance lors de
l'inversion sur des petites valeurs, ex. salaire total = 2. Donc on le
limite à une valeur supérieure à 400.
Atttention, 0 🎨 pour l'instant.
On garde les contrôles bloquants déjà implémentés.
On ajoute les contrôles de type avertissement qui peuvent faire appel à
des calculs.
Mael
Johan Girod