Gestion du mocking des modules pour Storybook

[Fansoa]

Contexte

Dans le cadre de l'utilisation de Storybook, il est impossible d'afficher des composants nécessitant des resources contextes particulières.

Quand faut-il Mock?

Il n'est pas nécessaire de mocker une resource externe à un composant d'interface:

• Si la ressource est provide par un contexte (dans ce cas on peut fournir le contexte via un provider dans le decorator de la story)

Il est nécessaire de mocker une ressource externe à un composant d'interface:

• Si la resource est provide par une logique interne dépendant d'un environnement non reproductible

Cas concret

Le composant Sidebar contient un "custom" Hook useNavigation qui return un tableau de configuration de la Sidebar. Pour construire le tableau de configuration de la Sidebar, useNavigation utilise le hook usePathname de Next qui récupère l'url courant pour comparer avec une donnée statique et ainsi ajouter la propriété current à true.

Il faut donc mock le module useNavigation pour retourner un tableau de configuration au composant Sidebar.

Comment mock un module dans Storybook

(Storybook - Mocking modules)[https://storybook.js.org/docs/writing-stories/mocking-data-and-modules/mocking-modules#mock-files-for-external-modules]

Problématique rencontré

Pour le moment, le mocking proposé par Storybook me semble trop invasif car cela touche au package.json, à la configuration de Typescript, mais aussi au type d'import du module que l'on souhaite mocker. (Pour le moment, je n'ai pas été capable de faire fonctionner le mock du module avec un export par défaut)

Décision

Je ne souhaite pas impacter les performances de mon application pour un utilitaire tel que Storybook. J'utiliserais le mocking de module quand je cela n'aura pas d'impact sur les performances de mon application.

En dernier recours, je pourrais utiliser le Container/Presentational Pattern au lieu du Hook Pattern afin de pouvoir éviter le mocking de module. Cela demanderais une factorisation des composants.

Conclusion

Ouverture d'une stratégie front-end dans le wiki afin de trouver une solution sans impact pour l'application