Migration

la migration depuis les versions antérieures de slate vers les versions 0 50 x n’est pas une tâche simple l’ensemble du framework a été repensé depuis la base cela a abouti à un ensemble beaucoup meilleur d’abstractions, ce qui vous permettra d’écrire moins de code mais le processus de migration n’est pas simple il est fortement recommandé qu’après avoir lu ce guide vous lisiez le didacticiels docid wo8v9j1len5tmbi9io7f original ainsi que les autres concepts docid\ fyn66gf1u7iohv47ffgpn afin de voir comment tous les nouveaux concepts sont appliqués différences majeures voici une vue d’ensemble des principales différences dans la version 0 50 x de slate d’un point de vue architectural json! le modèle de données est désormais composé de simples objets json auparavant, il utilisait des structures de données immutable js https //immutable js github io/immutable js/ c’est un changement majeur, qui débloque beaucoup d’autres choses espérons qu’il augmentera aussi les performances moyennes lors de l’utilisation de slate cela facilite également grandement les débuts pour les nouveaux utilisateurs ce sera un changement important à migrer, mais il en vaudra la peine interfaces le modèle de données est basé sur des interfaces auparavant chaque modèle était une instance d’une classe désormais, non seulement les données sont de simples objets, mais slate s’attend uniquement à ce que les objets implémentent une interface ainsi les propriétés personnalisées qui résidaient auparavant dans node data peuvent maintenant se trouver au niveau supérieur des nœuds espaces de noms beaucoup de fonctions utilitaires sont exposées comme une collection de fonctions utilitaires dans un espace de noms par exemple, node get(root, path) ou range iscollapsed(range) cela rend le code beaucoup plus clair car vous pouvez toujours voir rapidement avec quelle interface vous travaillez typescript la base de code utilise maintenant typescript travailler avec du json pur comme modèle de données, et utiliser une api basée sur des interfaces, sont deux choses facilitées par la migration vers typescript vous n’avez pas besoin de l’utiliser vous même, mais si vous le faites vous obtiendrez beaucoup plus de sécurité en utilisant les apis (et si vous utilisez vs code vous aurez une autocomplétion pratique quoi qu’il arrive !) moins de concepts le nombre d’interfaces et de commandes a été réduit auparavant sélection , annotation , et décoration étaient toutes des classes séparées elles sont maintenant simplement des objets qui implémentent l’interface plage auparavant bloc et en ligne étaient séparés ; ils sont maintenant des objets qui implémentent l’interface élément auparavant il y avait un document et un valeur , mais maintenant le éditeur de niveau supérieur contient les nœuds enfants du document lui même le nombre de commandes a également été réduit auparavant nous avions des commandes pour chaque type d’entrée, comme insérer du texte , inserttextatrange , inserttextatpath celles ci ont été fusionnées en un ensemble plus restreint de commandes plus personnalisables, par exemple insérer du texte qui peut prendre à path | range | point moins de packages afin de réduire la charge de maintenance, et parce que les nouvelles abstractions et apis dans les packages principaux de slate rendent les choses beaucoup plus simples, le nombre total de packages a été réduit des éléments comme slate plain serializer , slate base64 serializer , etc ont été retirés et peuvent être implémentés facilement côté utilisateur si nécessaire même le slate html deserializer peut maintenant être implémenté côté utilisateur (en 10 loc en tirant parti de slate hyperscript ) et les packages internes comme slate dev environment , slate dev test utils , etc ne sont plus exposés car ils constituent des détails d’implémentation commandes un nouveau concept de "commande" a été introduit (les anciennes "commandes" sont maintenant appelées "transforms" ) ce nouveau concept exprime l’intention sémantique d’un utilisateur éditant le document il permet également de trouver la bonne abstraction pour intercepter les comportements utilisateurs — par exemple pour changer ce qu’il se passe lorsqu’un utilisateur appuie sur enter ou backspace, etc au lieu d’utiliser des événements keydown vous devriez probablement plutôt remplacer les comportements des commandes les commandes sont déclenchées en appelant les fonctions principales editor elles circulent à travers une pile de type middleware, mais construite à partir de fonctions composées tout plugin peut remplacer les comportements pour augmenter un éditeur plugins les plugins sont désormais de simples fonctions qui augmentent l’objet éditeur qu’elles reçoivent et le renvoient ensuite par exemple, elles peuvent augmenter l’exécution de commandes en composant la fonction editor exec ou écouter les opérations en composant editor apply auparavant, elles reposaient sur une pile de middleware personnalisée, et n’étaient que des groupes de handlers fusionnés dans un éditeur désormais, nous utilisons une simple composition de fonctions (alias wrapping) éléments le caractère block ou inline est désormais un choix à l’exécution auparavant, il était intégré dans le modèle de données avec les attributs object 'block' ou object 'inline' désormais, le système vérifie si un « element » est inline ou non à l’exécution par exemple, vous pourriez vérifier que element type === 'link' et le traiter comme inline plus proche de react le rendu et la gestion des événements ne relèvent plus de la responsabilité d’un plugin auparavant, les plugins avaient un contrôle total sur la logique de rendu et de gestion des événements dans l’éditeur cela créait une mauvaise incitation à mettre toute la logique de rendu dans les plugins, ce qui plaçait slate dans une position où il devait encapsuler toute la logique de react, ce qui est très difficile à réaliser correctement à la place, la nouvelle architecture se concentre sur les aspects richtext pour les plugins, et laisse les aspects de rendu et de gestion des événements à react contexte auparavant, le composant <éditeur> jouait un double rôle une sorte d’objet « controller » ainsi que l’élément dom contenteditable cela entraînait beaucoup de maladresses dans la manière dont les autres composants interagissaient avec slate dans la nouvelle version, il existe un nouveau provider de contexte \<slate> et un composant \<modifiable> similaire à contenteditable en plaçant le provider \<slate> plus haut dans votre arbre de composants, vous pouvez partager l’éditeur directement avec des barres d’outils, des boutons, etc , grâce au hook useslate hooks en plus du hook useslate , il existe quelques autres hooks par exemple, les hooks useselected et usefocused aident à savoir quand rendre les états sélectionnés (souvent pour les void nodes) et puisqu’ils utilisent l’api de contexte de react, ils se re render automatiquement lorsque leur état change beforeinput nous utilisons désormais presque exclusivement l’événement beforeinput au lieu de dépendre d’une série de shims et des particularités des événements synthétiques de react, nous utilisons désormais l’événement standardisé beforeinput comme base il est entièrement supporté dans safari et chrome, sera bientôt supporté dans la nouvelle version de edge basée sur chromium, et est actuellement en cours d’implémentation dans firefox en attendant, quelques patchs permettent à firefox de fonctionner internet explorer n’est plus supporté dans le core par défaut sans historique la logique d’historique du core a enfin été extraite dans un plugin autonome cela facilite grandement la mise en œuvre de comportements d’historique personnalisés et cela garantit que les plugins disposent de suffisamment de contrôle pour augmenter l’éditeur de manière complexe, car l’historique l’exige sans mark les marks ont été supprimées du modèle de données de slate maintenant que nous pouvons définir des propriétés personnalisées directement sur les nœuds eux mêmes, vous pouvez modéliser les marks comme des propriétés personnalisées des text nodes par exemple, le gras peut être modélisé simplement comme une propriété bold true sans annotation de même, les annotations ont été supprimées du core de slate elles peuvent désormais être entièrement implémentées côté utilisateur en définissant des opérations personnalisées et en rendant des plages annotées via des decorations mais dans la plupart des cas, il est préférable d’utiliser des propriétés personnalisées sur les text nodes ou des decorations il n’y avait pas tant de cas d’utilisation qui bénéficiaient réellement des annotations réductions l’un des objectifs était de simplifier considérablement une grande partie de la logique de slate afin de faciliter sa maintenance et son évolution cela a été réalisé en refactorisant vers de meilleures abstractions de base sur lesquelles s’appuyer, en tirant parti des api dom modernes, et en migrant vers des modèles react plus simples pour vous donner une idée du changement en nombre total de lignes de code slate 8,436 > 3,958 (47%) slate react 3,905 > 1,954 (50%) slate base64 serializer 38 > 0 slate dev benchmark 340 > 0 slate dev environment 102 > 0 slate dev test utils 44 > 0 slate history 0 > 211 slate hotkeys 62 > 0 slate html serializer 253 > 0 slate hyperscript 447 > 345 slate plain serializer 56 > 0 slate prop types 62 > 0 slate react placeholder 62 > 0 total 13,807 > 6,468 (47%) la différence est vraiment importante ! et cela n’inclut même pas les dépendances qui ont été supprimées au passage