Supprime aussi redux-batched-action. Le code résultant est plus concis
(alors que l'on supprime une dépendance !), et plus clair car il y a moins
d'indirections pour se conformer aux API de redux-form.
Il s'agit d'une fonctionnalité non standard de JavaScript qui est peu
utilisée dans la base de code. Ajoute de la complexité pour les nouveaux
développeurs (configuration spécifique de l'environnement de dév) pour
trop peu de bénéfices.
- Ajout d'un avertissement (le stage n'est pas un contrat de travail)
- Ajout des traductions
- D'avantage d'utilisation de "rend non applicable"
- Une modification de parentDependency pour prendre un compte que
"contrat stage" est maintenant un enum CDI | CDD | Stage plutôt qu'un
boolean true | false.
Pour l'instant les choix sont CDI, CDD, ou Stage.
Modification du moteur concernant la désactivations des règles spécifiques
au CDD (la logique précédente nécessitait que `contrat . salarié . cdd`
soit une question, elle fonctionne maintenant avec une formule)
Les liens dans le markdown ne prenaient pas en compte le `basename`
configuré via react-router/history.
Utilisation de `react-markdown` au lieu de `marked` qui s'inter-opère
mieux avec notre UI.
Comme pendant l'évaluation et son objet cache, parsedRules est construit
au fur et à mesure du parsing sous la forme [dottedName]: parsedRule
Cela nous permet pendant le parsing de faire l'annotation de type et de
faire moins de boulot lors de l'évaluation
Problème :
- (presque fixé) dans l'inversion on produisait des références de variables pour le JSX
=> boucle infinie
- dans chiffre d'affaire, notre implé un peu bizarre fait une référence
de variables a priori circulaire, mais gérée par les variations. Or
pendant le parsing on parcourt évidemment toutes les branches sans les
évaluer. Sachant qu'on implémente ce cache parsedRules surtout pour les
unités, peut on garder la formule ainsi et simplement stocker 'chiffre
d'affaires': 'currently being parsed' pour éviter la boucle infinie ?
Car quand on parse et qu'on tombe sur une variable, on ne rentre pas
dans cette variable. Elle sera traitée par la suite dans le parseAll.
Ainsi on ne peut pas connaître son unité si elle a une formule
A = B * C
B = D / E
C unité km
D unité €
E unité km
Quand on tombe sur B dans A, B n'est pas encore parsée, et donc on ne
peut pas savoir que B est en € / km.
Il faudrait parser B, ce qui serait trop couteux. On pourrait
implémenter un cache au parsing, implémenter les unités comme des fonctions, ou encore gérer les unités lors de l'éval (ce qui est bête, car on n'a pas besoin des valeurs pour inférer les unités)
Plus simple que be7b2b8ac4e747b6a7cb4d56e2edc8544875f4c4
This feature was at first designed to work not only with boolean questions, but also applicability conditions and formulas. But lots of numeric formulas are also namespaces, with children in the computations themselves. Which, in the previous implementations, lead to lots of irrelevant checks. To be reintroduced better if needed
Maxime Quandalle
Johan Girod
Mael
Johan Girod