Comment se passer de store manager

Faire du front revient souvent à utiliser une librairie de state management en plus d'un framework. Mais parfois ce n'est pas la solution la plus optimisé. Voici un exemple de pourquoi et comment j'ai fait autrement.

Un peu de contexte

Chez Nextstore, nous éditions une interface permettant n'importe qui de fabriquer leur site e-commerce en no-code.

Les utilisateurs pouvaient drag and drop⁰ tous les composants de leurs sites, en éditer le contenu et le style, et customiser la manière dont ils accédaient à leurs données sur Shopify ou BigCommerce.

Le code généré par notre builder leur était accessible via un repo git, contenant leur site, mais également nos composants.

Nous fournissions en effet des composants pré-faits, avec une grosse orientation mobile. L’idée était d’optimiser le trafic sur mobile en améliorant les performances, mais aussi l’UX grâce à des interactions plus engageantes et typiques du mobile, tel que le swipe ou le snap-scroll⁰

.

Le plus bel exemple était le Drawer, un conteneur tactile glissant à la verticale permettant du progressive-disclosure⁰

Ce composant était généralement utilisé dans les pages produits de nos clients pour mettre en valeur le carrousel d’image, mais les utilisateurs pouvaient le mettre n’importe où ils le jugeaient nécessaire.

Le Drawer est un composant simple, mais dont la position dans l’écran peut impliquer tout un tas de changement pour le reste de l’app. Le rétrécissement d’un carrousel d’image par exemple, la diminution d’une taille de police ailleurs, peu importe. Dans la plupart des librairies de type React ou Vue, l’état — ou state – responsable de tous ces changements est externalisé dans un store via une librairie de state management. Comme Redux, VueX ou MobiX.

Par exemple, notre builder qui est une application stable, aux fonctionnalités et nombre de pages défini utilisait extensivement Jotai⁰.

Dans le cas des sites clients, ce fut différent.

L’app infinie

D’abord, il n’était pas possible de prédire exactement ce à quoi chaque app ressemblerait. Fabriquer un builder n’est pas comme coder une fonctionnalité pour un site en particulier. L’objectif est d’offrir le choix à l’utilisateur. Chacun de nos composants offrait la possibilité d’être utilisé n’importe où, autant de fois que nécessaire ou pas du tout. Donc exit toutes les solutions du style XState.

Cela n’empêche pas d’utiliser un store, mais cela rend la tâche plus compliquée. Nous avons d’abord essayé avec Redux, puis Recoil, avant de faire l’erreur classique de vouloir réinventer la poudre avec des contexts React.

Mais que ce soit avec les contexts⁰ ou une autre librairie, la maintenance du tronc commun de toutes nos app était compliqué. Parce que les composants pouvaient ne pas être là, nous devions mettre tout un tas de garde-fou, nous perdions souvent les avantages du SSR et les performances n’étaient vraiment pas bonnes malgré tous nos efforts. Nous avions l’impression de nous battre contre des fantômes.

Ensuite, sur une application classique, seuls les devs d’une même boite interviennent sur la codebase. Au pire, il y a des affrontements inter-équipes, mais rarement plus de drama. Nous offrions l’accès à notre codebase à nos clients qui pouvaient en faire potentiellement n’importe quoi. Et nous ne souhaitions pas que ce n’importe quoi puisse facilement atteindre nos composants.

En ce sens, le principe du store avec lequel n’importe qui peut interagir n’importe comment ne nous convenait pas. Nous voulions que nos state restent le plus proche possible de leur UI. Surtout, nous voulions avoir le contrôle sur la manière dont les utilisateurs modifieraient nos state depuis leur code.

Il était donc nécessaire d’avoir une architecture plus légère, flexible et dynamique, capable de s’adapter à tous les cas de figures.

La question était donc : laquelle ?

Le JS natif à la rescousse

J’adore faire de la veille technique. Et un jour, en parcourant MDN pour le plaisir, je suis tombé sur la page des Custom Events. Et ça m'a donnée une idée.

Si vous avez déjà fait du front, alors vous avez certainement utilisé les events natifs du DOM, comme "click" ou encore "scroll".

Et bien, vous pouvez fabriquer les vôtres sans mettre en péril l’Internet mondial. Voyez plutôt :

La classe CustomEvent vous permet d’enregistrer un évènement de votre cru avec un nom de votre invention et de faire passer des informations complémentaires au moment du dispatch.

const monEvent = new CustomEvent("mon-event", { detail: { ...myData } });
document.dispatchEvent(monEvent);

// Ailleurs dans mon app
document.addEventListener("mon-event", (event: CustomEvent<TypeDeMaData>) => {
  const { ...myData } = event.detail;
  /// faire un truc cool avec.
});

Dans notre cas, c’est exactement ce dont nous avions besoin. Un moyen de faire circuler l’information de nos states internes dans le reste de l’app avec un système de souscription.

Le code

Sur chacun de nos composants, nous avons alors défini une liste d’évènements à traquer, comme la position de notre fameux Drawer.

type Data = {/*...*/}

class MonEvent extends CustomEvent<Data> {
	static eventName = (id:string) => `event-du composant-${id}`;
	constructor(data: Data, id:string) {
		super(MonEvent.eventname(id), {
			detail: data,
			cancellable:false
		});
	}
}

function ComposantExterne({id, ...props}) {
	useEffect(() => {
		document.addEventListner(MonEvent.eventName(id), callback);
		return () => document.removeEventListner(MonEvent.eventName(id), callback);
	}, [id]);

	return (
		/// mon JSX
	);
}

// Ou encore :
function ButtonExterne({id, ...props}) {
const [state, setState] = useState(false);
	return (
		<button onClick={() => {
			const newState = !state; // juste histoire d'être synchro
			setState(newState);
			document.dispatchEvent(new MonEvent({state: newState ? "cliked" : "unclicked"}, id));
		}}>Faire un truc</button>
	);
}

Ben voilà. Nickel. Il ne nous reste plus qu’à “hookifier” cette solution :

// @/hooks/useCustomEventListener.ts
/* 
Cette classe imite les autres class events et permet d'envoyer n'importe laquelle dans le hook plus bas tout en profitant du typage de la data
*/
class GlobalEvent<Data> extends CustomEvent<Data> {
  static eventName: (() => string) | ((id: string) => string) = () => "";

  constructor(data: Data, id?: string) {
    super(GlobalEvent.eventName(id ?? ""), { detail: data, cancelable: false });
  }
}

type Args<T> = {  
	customEvent: typeof GlobalEvent<T>,
  id?: string, 
	callback?:(detail: T) => void
};

export function useCustomEventListener<EventDetail>({
  customEvent,
  id,
	callback
}: Args<EventDetail>): EventDetail | undefined {
  const [eventValue, setEventValue] = useState<undefined | EventDetail>(
    undefined
  );

  useEffect(() => {
    function handleCustomEvent(event: Event): void {
      if (event instanceof customEvent) {
        setEventValue({ ...event.detail });
      }
    }

    document.addEventListener(
      customEvent.eventName(id ?? ""),
      handleCustomEvent
    );

    return () =>
      document.removeEventListener(
        customEvent.eventName(id ?? ""),
        handleCustomEvent
      );
  }, [customEvent, id]);

  return eventValue;
}

// @/components/SomeComponents.tsx
function SomeComponent() {
  const { state } = useCustomEventListener(DrawerSwippingEvent);
  // A condition que la class DrawerSwippingEvent spécifie sa version de EventDetail,
  // il n'est pas nécessaire de le spécifier ici, d'ou l'interet des class.

  return <p>Le drawer est {state.position > 0 ? "ouvert" : "fermé"}</p>;
}

La méthode addEventListener ne permet pas de récupérer d’éventuels retours de son callback. On est donc obligés de répercuter le contenu de l’ event dans un deuxième state. Mais soyez sans crainte, car React est suffisamment optimisé, particulièrement depuis la version 18, pour “batcher” toutes ces updates de state en même temps, même dans un callback, même dans de l’async.

Vous pouvez vérifier vous même dans cet exemple:

Dans l'autre sens

Jusque là nous avons vu comment envoyer de la données, mais nos composants pouvait également recevoir certaines informations, comme par exemple s'ouvrir ou scroller jusqu'à certaine position.

Mais là le code est encore plus simple, il n'y a même pas besoin de hook react puisqu'il s'agit d'une simple fonction. Ecrivons en un tout de même pour soigner notre DX :

type Args<T> = {
	customEvent: Global<T>;
	id?:string;
}

export function useCustomEventEmitter<EventDetail>({
  customEvent,
  id,
}: Args<EventDetail>) {
  return (data: EventDetail) => document.dispatchEvent(new CustomEvent(data, id));
}

Et voilà !

Wow ! Est-ce que l’on vient d’inventer un nouveau store-manager révolutionnaire ? Absolument pas 🤣. Mais vous remarquerez que cette solution permet à peu de frais de faire transiter de l'information entre n'importe quels composants de la page sans avoir à utiliser de Wrapper au sommet de l'application. C'est à dire sans utiliser de store, tout en conservant la réactivité de notre framework préféré.

Dans notre cas, cette organisation nous a été très utile. Que ce soit pour itérer sur nos composants sans les transformer en code spaghetti, ou pour permettre à nos clients de les utiliser plus facilement.

Conclusion

Grâce à cette méthode, nous n’avions plus besoin de réfléchir à la hiérarchie des éléments dans leurs interactions avec d’autres éléments distants dans un contexte d’incertitude. Nous n’avions plus à nous préoccuper de rendre certains éléments indispensables ou non. Nos composants et ceux de nos clients pouvaient être déposés n’importe où dans notre AST⁰ maison et discuter avec n’importe lequel dans la page.

Et c'était quand même très pratique.