Et pour faire passer les tests jest au passage.
A noter : il faudra vraiment se pencher sur la notion d'applicable / non applicable
Une variable non applicable a une valeur '0' / 'false', mais une variable
à false n'est pas considérée comme non applicable. Je pense qu'il serait avantageux
de simplifier le modèle en introduisant une symetrie entre applicable si et la valeur
d'une variable.
Dans 16ae29bdc, j'avais supprimé la cotisation de 1% sur les CDD pour
financer le CIF. Cette cotisation n'avait en fait pas été supprimée mais
remplacée par une cotisation pour financer le CPF...
This reverts commit 16ae29bdcc.
Outils
======
Ce commit retire le tooling de Flow, et ajoute le support de TypeScript
pour les fichiers .ts et .tsx. Il n'est pas nécessaire de tout migrer
d'un coup ce qui facilite la transition. On garde en effet le
compilateur Babel avec un preset TypeScript (ce qui permet donc de
retirer à la fois les types Flow et TypeScript) plutôt que d'utiliser le
compilateur standard pour la conversion du code. Cela permet aussi de
mieux s'intégrer avec d'autres outils, notamment les test-runners.
Ajout d'une nouvelle commande `yarn run type-check`, intégrée dans
CircleCI.
Par ailleurs ajout du support de l'opérateur ?? pour donner des valeurs
par défaut (nullish-coalescing-operator).
Typage des libraires tierces
============================
Les principales libraires que nous utilisons ont un typage TypeScript de
bon niveau, ce qui facilite l'intégration. J'ai mis à jour react-i18next
et i18next afin de corriger un problème de typage.
Typage du code
==============
Le typage est loin d'être complet dans ce commit, en particulier il
manque les types relatifs au state Redux, ainsi qu'au moteur (règle,
explication). Néanmoins le typage des contextes fonctionne, en
particulier sitePaths (avec un type récursif non trivial !) qui a déjà
permis de détecter un lien mort.
Le typage des "paths" (Components/, Règles/, etc.) fonctionne bien, y
compris avec l'auto-complétion automatique des import par Typescript.
TypeScript se révèle déjà bien agréable dans VSCode (auto-complétion,
refacto, etc.) ! Reste à migrer progressivement le reste du code !
Le paramètre SMIC utilisé dans le calcul des réductions, en particulier
de la réduction générale, doit prendre en compte les heures supplémentaires.
Cette non prise en compte nous conduisait à sur-estimer le montant des
cotisations sociales sur les heures supplémentaires.
Ajout de tests de non-regressions des calculs afin d'éviter de déployer
silencieusement des effets de bord non-désirés dans les règles de calculs.
J'ai ajouté Jest pour sa fonction de snapshot testing qui est
particulièrement adaptée pour ce type de cas (voir #717). J'ai essayé
avec mocha-snapshot sans succès.
J'ai eu un petit peu de mal à configurer Jest, car il n'est pas possible
de ré-utiliser la configuration Webpack, qu'il faut alors dupliquer. C'est
pourquoi j'ai limité l'utilisation de Jest aux seuls tests de snapshot.
À voir s'il y a un intérêt à migrer les tests Mocha vers Jest ultérieurement.
Fixes#717
Ces fonctions n'étaient utilisées qu'une fois ou deux et constituent des
indirections inutiles : getIframeOption, parseDataAttributes,
setToSessionStorage, getFromSessionStorage et isNumeric.
Préférer les fonctions de la "bibliothèque standard": sessionStorage et
URLSearchParams.
* 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".
- On utilise un nouveau composant qui se base sur la dernière version de l'api SIRENE
- On sépare les données entre la simulation des cotisations et la création d'entreprise
- On gagne des lignes !
Supprimée au niveau des cotisations patronales dans fb54d4c, ce commit
ré-intégre ce coût au niveau d'une nouvelle variable "coût du travail"
qui inclut également les aides différées.
Note: une variable "coût d'embauche" existait précédemment mais n'était
plus utilisée 4784bcd2
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.
Quand une variable est destinée à être saisie par l'utilisateur, on veut
qu'il saisisse 50, pas 0.5 pour exprimer 50%.
On pourrait lui faire saisir 50 et convertir en direct vers la vraie
valeur de 0.5, mais c'est compliqué aujourd'hui dans reduxForm
(l'attribut "normalize" ne suffit pas, car la valeur 0.5 sera visible
après un bref instant de debounce).
Je pense qu'il serai quand même mieux que nous stockions les variables
qui sont des ratios comme 0.5 et que l'UI se charge d'afficher et de
faire saisir ces valeurs sous forme 50%.
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.
Suite aux retours utilisateurs rassemblé par l'Acoss (cc Agnes Nardon) :
- Uniformise les nom de tous les champs entre les différents simulateurs
- Pour la comparaison des régimes, on ne parle plus du CA, mais du montant dégagé pour la rémunération du dirigeant (plus clair)
- Supprime la notion de charge pour les auto-entrepreneur
- Tant que la simulation complète de l'entreprise n'est pas développé (cf #562), on enlève la notion de chiffre d'affaires des simulateurs de revenus. Elle est en effet triviale à calculer (rem total + charges) et laisse perplexe les utilisateurs même les plus renseignés
Evidememnt, ça pose problème : on n'a pas encore retourné la valeur d'un
noeud (ex. cotisation X) qu'on demande son évaluation dans le contrôle
(cotisation X > 450)
- Enlève le statut SNC
- Change la responsabilité par Société vs EI
- Répare un bug dans l'algo de choix de réponse qui retournait une question aboutissant à un choix null
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
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...
Johan Girod
Maxime Quandalle
Maxime Quandalle
Mael
Johan Girod
Marc Pasteur