Tous les éléments à traduire (via la balise <Trans> ou la fonction 't')
sont analysé statiquement. Si il manque une traduction, la PR est bloquée
Ajoute un script de traduction automatique via `yarn run i18n:ui:translate`
Met à jour CONTRIBUTING.md avec les infos sur la traduction
Cela permet l'inférence de type à partir des fichiers js qui ne sont pas
encore convertis en TypeScript.
Par ailleurs suppression des dernières traces de Flow.
Ajout d'options plus strictes pour dans la config tsconfig.js
Gros changements en perspective :
- Supprime la notion de période, au bénéfice de celle d'unité
(`période : mensuelle` devient `unité: €/mois`)
- Améliore les rapports d'erreur avec des messages plus clair
- Ajoute un avertissement lorsque des types ne sont pas compatible
- Ajoute la conversion automatique d'unité dans le moteur
- Ajoute une notion d'unité par défaut de la simulation,
c'est l'unité vers laquelle les règles qui ne spécifient pas
d'unité seront converties
- Ajoute une notion d'unité par défaut des règles, qui spécifie
l'unité de la règle qui prévaut lorsque qu'il n'y a pas
d'unité par défaut de la simulation (utile pour les question ou
pour s'assurer du bon type d'une règle)
* Définition à partir du nom complet en notation pointée (plutôt que
comme deux attributs indépendants "name" et "espace")
* Structure de données de premier niveau "dictionnaire" plutôt que liste,
s'aligne mieux avec notre contrainte d'unicité des noms
* Possibilité de définir les règles à partir d'une liste dans les tests,
dans ce cas il ne faut plus utiliser l'attribut "espace" mais renseigner
directement la notation pointée dans le "nom".
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
Johan Girod
Mael