Conventions et outils

26 min

1. Conventions de nommage

1.1 Nomenclature des fichiers

Les fichiers de configuration utilisent désormais le kebab-case.

Exemple :

envVars.yml → env-vars.yml

Le fichier env-vars.yml est toujours traité par la bibliothèque de vérification d’environnement (checkenv).

2. Mise à jour des environnements et dépendances

2.1 Versions des outils

Les environnements techniques ont été mis à jour pour profiter des dernières améliorations de performance et de sécurité.

Node.js : utilisation de la version LTS.

3. Évolutions de l’API client @fasstech/oip-starter-utils

La version OIP v4 de la librairie @fasstech/oip-starter-utils (OIP Starter Utils) introduit plusieurs changements structurels et logiques majeurs dans son API client. Ces évolutions visent à simplifier l’intégration, renforcer la cohérence des API et unifier la gestion du contexte applicatif.

3.1 Nouveaux exports du module @fasstech/oip-starter-utils/app

Avant (v3)

import {
  start,
  useProcess,
  Router,
  Tokens
} from '@fasstech/oip-starter-utils/app';

Après (v4)

import {
  start,
  useProcess,
  Router
} from '@fasstech/oip-starter-utils/app';

Évolution :

L'objet Tokens n’est plus exposé publiquement : il n'a plus à être manipulé manuellement par le développeur (gestion centralisée des credentials et du token d’authentification client).

3.2 Fragment ProcessFragment

Avant (v3)

const ProcessFragment = gql`
  fragment ProcessFragment on ExtendedProcess {
    projectId
    viewId
    metadata
    sessionId
  }
`;

Après (v4)

const ProcessFragment = gql`
  fragment ProcessFragment on ExtendedProcess {
    projectId
    viewId
    viewData
    sessionId
  }
`;

Évolution :

La propriété metadata est remplacée par viewData, reflétant une refonte du typage GraphQL côté serveur pour une meilleure cohérence front/back.

3.3 useCustomHandlers → customHandlers

Avant (v3)

useCustomHandlers était un hook retournant un objet customHandlers :

const useCustomHandlers = () => {
  const myCustomHandler = () => { /* logic */ };

  return {
    customHandlers: { myCustomHandler }
  };
};

startApp({
  useCustomHandlers,
});

Après (v4)

customHandlers devient une propriété directe passée à start :

const myCustomHandler = () => { /* logic */ };
const myOtherCustomHandler = () => { /* logic */ };

start({
  customHandlers: { myCustomHandler, myOtherCustomHandler },
});

Évolution :

La configuration devient plus déclarative et plus lisible.

Plus besoin de définir un hook dédié.

3.4 Fusion de ctx et ctxPolicy

Avant (v3)

Deux propriétés géraient la récupération du token client lors du décrochage :

ctx : contexte applicatif

ctxPolicy : stratégie de récupération du token

Valeurs possibles (ctxPolicy v3) :

parameters

local-storage

session-storage

url-params

shadow-crm

Après (v4)

Les deux propriétés sont fusionnées en une seule : ctx.

Valeurs possibles (ctx v4) :

'local-storage'

'session-storage'

'shadow-crm'

'url'

{ token: string }

{ projectId: string }

Exemples :

Depuis le local storage :

localStorage.setItem('ctxToken', 'my-ctx-client-token');

start({
  ctx: 'local-storage'
});

Depuis un paramètre :

start({
  ctx: { token: 'my-ctx-client-token' }
});

Depuis l’URL :

https://my.oav.fasst/?token=my-ctx-client-token

start({
  ctx: 'url'
});

Évolution :

ctx devient une interface unifiée permettant de définir comment récupérer le token ou le projet courant.

3.5 Renommage et regroupement des propriétés d’erreur

Avant (v3)

rootDivId

Pages d’erreur définies individuellement :

badRequestPage

unauthorizedPage

forbiddenPage

notFoundPage

internalServerError

Après (v4)

rootDivId devient rootElementId.

Les pages d’erreur sont regroupées sous une propriété unique errorPages :

type ErrorPages = {
  badRequestPage?: () => ReactNode;
  unauthorizedPage?: () => ReactNode;
  forbiddenPage?: () => ReactNode;
  notFoundPage?: () => ReactNode;
  internalServerErrorPage?: () => ReactNode;
};

Évolution :

Rationalisation de la configuration des pages d’erreur.

3.6 Composant Router : bundle → views

Avant (v3)

<Router bundle={ViewsBundle} />

Après (v4)

<Router views={ViewsBundle} />

Évolution :

Renommage dans le cadre de la standardisation de la nomenclature autour des “views”.