Document Editor & Pagination Engine

Le package existant reconstruisait la pagination d'une manière qui ne tenait pas sous charge : le timing et la fréquence des reconstructions, combinés à une mesure du DOM peu sûre, provoquaient à la fois des coupures de page erronées et une latence de saisie sur les longs documents.

Ma première tentative a été une reconstruction incrémentale — ne recalculer que la zone touchée par un changement plutôt que tout le document. Elle fonctionnait sur les petits documents, mais lâchait de nouveau quand le nombre de pages et de mots augmentait : le même blocage revenait, simplement à un seuil plus élevé.

Je l'ai remplacée par trois changements : limiter la fréquence d'exécution des reconstructions, reporter le travail non urgent aux moments d'inactivité, et sécuriser la mesure du DOM pour qu'elle cesse de s'entremêler avec les changements de mise en page. Cette combinaison a tenu sur les longueurs de document qui comptaient vraiment.

J'ai construit un hook de suivi de page qui repère les nœuds de page dans le document, calcule quelle page est visible au scroll, applique un debounce aux mises à jour et écrit la page courante dans le store d'état de l'éditeur — affichée dans le pied de l'éditeur sous la forme « page courante sur total ».

Créer un fichier à partir d'un upload exigeait de connaître son nombre de pages dès le départ. J'ai ajouté une extraction du nombre de pages qui lit les uploads PDF avec pdfjs-dist et les uploads Final Draft (FDX) avec le parser FDX existant du produit, puis transmet ce nombre dans le parcours de création de fichier pour l'enregistrer sur la fiche du fichier.

J'ai étendu les helpers d'enregistrement de fichiers d'Express pour que la page courante puisse persister, et étendu l'état côté client et le CSS de l'éditeur pour que la mise en page de la pagination tienne de bout en bout.