Gestion du state au niveau des formulaires

[maxgfr]

Etat actuel

Nous utilisons actuellement react final-form au sein de tous les simulateurs pour gérer notre state. Pour pouvoir récupérer de la données supplémentaires, nous sommes obligés de passer par une seconde library externe react final-form-listeners.

Limites de cette approche

1. Utilisation de de listeners au sein du code

Pour pouvoir observer le changement d'un state nous sommes obligés de le placer dans le jsx. Je ne pense pas que ça soit la meilleur des approches pour pouvoir écouter des changements.

{({ input }) => (
          <OnChange name="echelon">
            {(coefficient) => {
              if (coefficient) {
                const { groupe, labels } = groupeLabelByCoeff.get(coefficient);
                setLabels(labels);
                input.onChange(groupe);
              } else {
                setLabels(null);
              }
            }}
          </OnChange>
        )}

2. Gestions du state au sein de l'application

Nombreuses, sont les composants au sein du code, non optimisé, rentrant en conflit avec la gestion des listeners, e.g Informations.jsx qui utilise des functions qui reloadés à chaque changement du DOM.

Cela fut problématique lorsqu'on envoya des events à Matomo.

Problème corrigé ici : #4222 avec l'utilisation de useCallback

function StepInformations({ form }) {
  const { values } = form.getState();
  const { ccn, criteria = {} } = values;
  const idcc = ccn ? ccn.num : 0;

  const initialSituations = getSituationsFor(allSituations, { idcc });
  const possibleSituations = filterSituations(initialSituations, criteria);
  const nextQuestionKey = getNextQuestionKey(
    possibleSituations,
    criteriaOrder,
    criteria
  );
  const nextQuestionOptions: any = getOptions(
    possibleSituations,
    nextQuestionKey
  );
  const pastQuestions = getPastQuestions(
    initialSituations,
    criteriaOrder,
    criteria
  );
 ...
 return (<>...</>);
}

3. Récupération du state un peu n'importe où

Je trouve qu'il manque une reel cohérence au niveau des éléments qui exploite le state de final-form des sous composants uniquement lié à de la gestion de l'UI utilisent via le contexte final-form pour afficher de l'information. Ce n'est pas du tout en accord avec le principe de Single Responsibility des composants React

4. L'utilisation du contexte qui est non optimisé

D'un point de vue de la performance, à chaque fois que le context est consumé ou changé, les components vont se re-render. Lors d'une mauvaise ou non gestion des useEffect ou useMemo (ou l'utilisation de PureComponent), il se peut que récupérer des valeurs d

Cette problématique ouvre une autre concernant l'utilisation du PublicodeContext.... (l'ouverture d'une prochaine discussion sûrement),

Liens :

• https://leewarrick.com/blog/the-problem-with-context/
• https://saul-mirone.github.io/performance-optimization-in-react-context/

5. L'utilisation de Field

  <Field
      name={name}
      validate={isNumber}
      subscription={{ error: true, invalid: true, touched: true, value: true }}
    >
      {({ input, meta: { touched, error, invalid } }) => (
        <UID>
          {(id) => (
            <>
              {label && (
                <Question required={required} htmlFor={`currency-${id}`}>
                  {label}
                </Question>
              )}
              <StyledWrapperInput>
                <Input
                  id={`currency-${id}`}
                  {...inputProps}
                  {...input}
                  type="number"
                  invalid={touched && invalid}
                  icon={icons.Euro}
                />

                {error && touched && invalid ? (
                  <InlineError>{error}</InlineError>
                ) : null}
              </StyledWrapperInput>
              {children}
            </>
          )}
        </UID>
      )}
    </Field>

Voici l'example d'un composant qui utilise le HOC de react-final-form, ici nous voyons bien que c'est super orienté côté front. Je ne pense pas que ça soit du côté la limite se fait au niveau de la génération de l'error.

6. Le design du formulaire

Actuellement, notre utilisation du formulaire se fait à travers plusieurs étapes qui re-render des composants nouveaux (dont certains sont dynamiques en fonction des informations saisies)

La complexité se fait au niveau de l'exploitation et de la generation des states. On ne sait plus quel champs sont liées aux field utilisée par final-form.

Final-form est bien côté formulaire simple (formulaire de contact), or dans notre use-case où l'application est basée dessus, on trouve vite la limite....

Solution envisagé

Utiliser un state global, qui permet de diviser la responsabilité entre l'action géré par le state globale, et l'affichage visuelle des composants :

• https://github.com/pmndrs/zustand
• https://github.com/pmndrs/jotai
• https://github.com/reduxjs/redux

[maxgfr]

Proposition de solution

zustand

Source : #4231

• Réécriture des composants en ayant une logique orientée front
• Mise en place de zustand

[m-maillot]

Après étude, il est possible d'améliorer l'outil actuel étape par étape pour obtenir une approche équivalente via le reducer déjà présent dans le simulateur.

L'approche est disponible sous forme de POC dans le commit 2dfb3bf

Voici les étapes envisageables pour passer sur ce nouveau format:

• Remplacer l'attribut component sur le State par une fonction prenant le form en paramètre et retournant le Composant (exemple)

• Eviter de passer le form sur les composants n'ayant pas besoin (props drilling)

• Créer un nouveau Wizard simplifié pour le simulateur de préavis à la retraite

• Détecter les changements avec le Spy de react-final-form

• Brancher le nouveau Wizard sur le simulateur de préavis à la retraite

• Utiliser le reducer pour retirer petit à petit l'utilisation du form dans les composants Step

• Utiliser le reducer pour retirer petit à petit le push matomo des composants Step

Tout ceci devra évidemment s'accompagner de TU :)

[maxgfr]

c'est niiiiiiice