* ✨ Simplifie la lecture de l’action SET_SIMULATION - “return early”
* ✨ Make automatic translation more fail-safe
* 🎨 Fix visuals for Overlay component
* ✨ Make Banner component more versatile
* Share simulation banner
* Ajout des identifiants courts pour les objectifs
* Dé/sérialisation search params <-> situation & targetUnit, basée sur
une logique générique (typeof)
* Suppression dans l'URL des search params correspondant à des
noms de règles ou identifiant courts
* Banner de partage, avec modale ou Navigator.share si disponible.
Co-authored-by: Alexandre Hajjar <alexandre.hajjar@gmail.com>
* URL with state: remove targetUnit
* serializeEvaluation for url sharing
* serializeEvaluation for number, boolean, string
* use this serialization in url search params
* for now, no support for Objects (like localisation)
Co-authored-by: Johan Girod <dev@johangirod.com>
* 🖋️ Quelques légères modifications de nom pour les identifiants courts
Co-authored-by: Paul Chavard <github@paul.chavard.net>
Co-authored-by: Johan Girod <dev@johangirod.com>
close#552
C'est parfois pratique de pousser sur master, mais il faudrait ajouter
une étape de confirmation pour éviter ce type d'erreur...
---
Revert "🔥 Supprime Ramda du moteur"
This reverts commit 269027a6a1.
Déplace:
mon-entreprise/source/sites/publi.codes → publicodes/site
mon-entreprise/source/sites/mon-entreprise.fr → mon-entreprise/source/site
La config Webpack du site publicodes reste encore liée à celle de
mon-entreprise.fr, il faudra la dissocier quand nous déplacerons le
projet publicodes dans son propre dépôt.
Afin de résoudre rapidement un problème lié au build de ce paquet. Il
faudrait faire un travail plus approfondi pour :
- séparer les styles de mon-entreprise des styles de publicodes-react
- choisir une convention unique pour la gestion du CSS de
publicodes-react, en y intégrant la possibilité de personnaliser les
styles pour un intégrateur (actuellement on fait un mixte de classes
CSS "classiques", de styled-component, et de prop `style={{}}`).
Lorsque l'on cherche un nom de règle, on laisse la possibilité à
une règle de se référencer elle même, mais alors cette résolution
est la dernière à être envisagée.
Dans l'exemple :
```yaml
b: 5
a . b: b
```
`a . b` référence bien `b` qui vaut `5`
Et dans celui ci :
```
a: 0
a . b:
remplace:a
par: b * 5
valeur: 2
```
`a . b` remplace `a` en la multipliant par sa propre valeur (ici 2)
fix#1081, fix#1083
La vérification de l'applicabilité du parent faisait un aller/retour
inutile entre la règle enfant et la règle parent, à l'origine d'une
régression de performance.
* ⚙️ Sort les fonctions JSX de l'AST
Remplace la fonction makeJsx par un composant React <Explanation />
Déplace presque tout le code React dans le répertoire components/ en
prévision de sa séparation dans un paquet dédié.
* ⚙️ Renomme le nœud "replacement" en "replacementRule"
* ⚙️ Ajout d'un attribut visualisationKind pour les mécanismes transformées
* ⚙️ Retours PR 1275
- 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
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é.
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).
- é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()
Modifie l'API de la fonction `evaluate` pour transmettre le contexte
avec `this`, ce qui simplifie l'interface de ces fonctions.
L'objet `this` (qui contient `this.parsedRules`, `this.situation`,
`this.evaluate`, etc.) est un interpréteur Publicodes, mais nous n'avons
pas besoin de créer une nouvelle abstraction car cet objet présente
exactement la même interface que l'objet public exposé dans
`publicodes/index.ts` et c'est donc l'interface publique qui est
utilisée dans les appels internes.
Ce commit parachève la sortie de l'ensemble des functions "evaluate" de
l'AST et ajoute un "nodeKind" sur chaque nœud afin de les associer à la
bonne function d'évaluation.
L'API pour les mécanismes pourra être améliorée afin de ne pas appeler
`registerEvaluationFunction` sur chaque mécanisme mais en standardisant
l'interface exportée par les mécanismes, par exemple
export { name, parse, evaluate, render }
Par ailleurs il devrait être facile de sortir les fonctions `jsx` en se
basant sur les mêmes "nodeKind".
Enfin, il faudra nettoyer l'AST pour supprimer les attributs inutilisés
et ajouter du typage fort.
Maxime Quandalle
Mael
Maxime Quandalle
Alexandre Hajjar
Johan Girod
Johan Girod