Migrer

migrer des versions antérieures de slate vers les 0 50 x versions n'est pas une tâche simple l'ensemble du cadre a été reconsidéré depuis le début cela a abouti à un bien meilleur ensemble 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 l'original docid\ nbgdlv7kxnu1xta yemzu et les autres docid 0vq0xibfbgmdioyuen62s pour voir comment tous les nouveaux concepts sont appliqués différences majeures voici un aperçu des différences majeures dans la 0 50 x version de slate du point de vue architectural json ! le modèle de données est maintenant composé d'objets json simples auparavant, il utilisait des https //immutable js github io/immutable js/ structures de données c'est un changement énorme, et un qui débloque beaucoup d'autres choses espérons que cela augmentera également la performance moyenne lors de l'utilisation de slate cela facilite également beaucoup le démarrage pour les nouveaux venus ce sera un grand changement à migrer, mais cela 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 maintenant, non seulement les données sont des objets simples, mais slate s'attend également à ce que les objets implémentent une interface ainsi, les propriétés personnalisées qui se trouvaient auparavant dans node data peuvent maintenant vivre au niveau supérieur des nœuds espaces de noms un grand nombre de fonctions d'aide sont exposées sous forme de collection de fonctions d'aide 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 qui ont été facilitées par la migration vers typescript vous n'avez pas besoin de l'utiliser vous même, mais si vous le faites, vous bénéficierez d'une sécurité beaucoup plus grande lors de l'utilisation des api (et si vous utilisez vs code, vous bénéficierez d'une belle autocomplétion de toute façon !) moins de concepts le nombre d'interfaces et de commandes a été réduit auparavant sélection , annotation , et décoration étaient auparavant des classes séparées maintenant, ce sont simplement des objets qui implémentent l' interface de plage auparavant, bloc et en ligne étaient séparés ; maintenant, ce sont des objets qui implémentent l' interface d'élément auparavant, il y avait un document et valeur , mais maintenant le éditeur 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 inserttext , inserttextatrange , inserttextatpath celles ci ont été fusionnées en un ensemble plus petit de commandes plus personnalisables, par ex inserttext qui peut prendre à chemin | plage | point moins de paquets dans une tentative de réduire la charge de maintenance, et parce que la nouvelle abstraction et les api dans les paquets principaux de slate rendent les choses beaucoup plus faciles, le nombre total de paquets a été réduit des choses comme slate plain serializer , slate base64 serializer , etc ont été supprimés et peuvent être implémentés dans l'espace utilisateur facilement si nécessaire même le slate html deserializer peut maintenant être implémenté dans l'espace utilisateur (en 10 loc en utilisant slate hyperscript ) et des paquets internes comme slate dev environment , slate dev test utils , etc ne sont plus exposés car ce sont des détails d'implémentation commandes un nouveau concept de "commande" a été introduit (les anciennes "commandes" s'appellent maintenant "transformations" ) ce nouveau concept exprime l'intention sémantique d'un utilisateur modifiant le document et ils permettent la bonne abstraction pour exploiter les comportements des utilisateurs—par exemple, pour changer ce qui se passe lorsqu'un utilisateur appuie sur entrée, ou sur retour arrière, etc au lieu d'utiliser keydown événements, vous devriez probablement remplacer les comportements de commande à la place les commandes sont déclenchées en appelant les editor fonctions de base et elles traversent une pile semblable à un middleware, mais construite à partir de fonctions composées tout plugin peut remplacer les comportements pour augmenter un éditeur plugins les plugins sont maintenant de simples fonctions qui augmentent l' éditeur objet qu'ils reçoivent et le retournent à nouveau par exemple, ils peuvent augmenter l'exécution de la commande en composant la editor exec fonction ou écouter des opérations en composant editor apply auparavant, ils s'appuyaient sur une pile middleware personnalisée, et ils n'étaient que des sacs de gestionnaires qui étaient fusionnés dans un éditeur maintenant, nous utilisons de la composition de fonctions classiques (c'est à dire l'encapsulation) à la place éléments la nature de bloc et d'inline est maintenant un choix à l'exécution auparavant, cela était intégré dans le modèle de données avec le objet 'block' ou objet 'inline' attributs maintenant, il vérifie si un "élément" est inline ou non à l'exécution par exemple, vous pourriez vérifier si element type === 'link' et le traiter comme inline plus react ish le rendu et la gestion des événements ne sont plus une préoccupation des plugins auparavant, les plugins avaient un contrôle total sur la logique de rendu et de gestion des événements dans l'éditeur cela crée une mauvaise incitation à commencer à mettre toute la logique de rendu dans les plugins, ce qui place slate dans une position d'être un wrapper autour de tout react, ce qui est très difficile à bien faire au lieu de cela, la nouvelle architecture a des plugins concentrés uniquement sur les aspects richtext, et laisse les aspects de rendu et de gestion des événements à react contexte auparavant, le \<editor> composant faisait double emploi en tant que sorte d'objet "contrôleur" et aussi l'élément dom contenteditable cela a conduit à beaucoup de maladresses dans la façon dont d'autres composants fonctionnaient avec slate dans la nouvelle version, il y a un nouveau \<slate> fournisseur de contexte et un \<editable> composant de type contenteditable en plaçant le \<slate> fournisseur plus haut dans votre arbre de composants, vous pouvez partager l'éditeur directement avec des barres d'outils, des boutons, etc en utilisant le useslate hook crochets en plus du useslate crochet, il existe une poignée d'autres crochets par exemple, le useselected et usefocused crochets aident à savoir quand rendre les états sélectionnés (souvent pour les nœuds vides) et comme ils utilisent l'api context de react, ils se re rendent automatiquement lorsque leur état change beforeinput nous utilisons maintenant l' beforeinput événement presque exclusivement au lieu de compter sur une série de shims et les particularités des événements synthétiques de react, nous utilisons maintenant l' beforeinput événement comme notre référence il est entièrement pris en charge dans safari et chrome, sera bientôt pris en charge dans le nouveau edge basé sur chromium, et est actuellement en cours de développement dans firefox en attendant, il existe quelques correctifs pour faire fonctionner firefox internet explorer n'est plus pris en charge dans le cœur par défaut sans historique la logique de l'historique de base a maintenant enfin été extraite dans un plugin autonome cela facilite beaucoup la mise en œuvre de comportements d'historique personnalisés et cela garantit que les plugins ont suffisamment de contrôle pour augmenter l'éditeur de manière complexe, car l'historique l'exige sans marque les marques ont été supprimées du modèle de données slate maintenant que nous avons la possibilité de définir des propriétés personnalisées directement sur les nœuds eux mêmes, vous pouvez modéliser les marques comme des propriétés personnalisées des nœuds de texte par exemple, le gras peut être modélisé simplement comme un gras vrai propriété sans annotation de même, les annotations ont été supprimées du cœur de slate elles peuvent maintenant être entièrement mises en œuvre dans l'espace utilisateur en définissant des opérations personnalisées et en rendant des plages annotées à l'aide de décorations mais dans la plupart des cas, il est préférable d'utiliser des propriétés de nœuds de texte personnalisées ou des décorations de toute façon il n'y avait pas tant de cas d'utilisation qui bénéficiaient des annotations réductions un des objectifs était de simplifier considérablement une grande partie de la logique dans slate pour faciliter sa maintenance et son itération cela a été réalisé en refactorisant pour de meilleures abstractions de base sur lesquelles on peut 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 dans le 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%) c'est une différence assez importante ! et cela n'inclut même pas les dépendances qui ont été éliminées dans le processus également