Journal des modifications

ceci est une liste de changements apportés à slate avec chaque nouvelle version jusqu'à 1 0 est publié, les changements majeurs seront ajoutés sous forme de mises à jour mineures, et les changements plus petits, de niveau correctif, ne seront pas notés car la bibliothèque évolue rapidement en version bêta ⚠️ jusqu'à ce que https //github com/atlassian/changesets/issues/264 soit résolu, chaque package maintiendra son propre changelog individuel, que vous pouvez trouver ici https //github com/ianstormtaylor/slate/tree/71ff94c8d866a3ad9582ec4b84258d99d508fd70/packages/slate/changelog md https //github com/ianstormtaylor/slate/tree/71ff94c8d866a3ad9582ec4b84258d99d508fd70/packages/slate history/changelog md https //github com/ianstormtaylor/slate/tree/71ff94c8d866a3ad9582ec4b84258d99d508fd70/packages/slate hyperscript/changelog md https //github com/ianstormtaylor/slate/tree/71ff94c8d866a3ad9582ec4b84258d99d508fd70/packages/slate react/changelog md 0 61 — 29 mars 2021 changement majeur nouveaux customtypes pour editor, element, text et d'autres objets spécifiques à l'implémentation une meilleure typage avec typescript vous permet d'ajouter des customtypes pour l'éditeur slate ce changement nécessite que vous configuriez vos types au début c'est un nouveau concept, alors veuillez lire la nouvelle documentation typescript ici https //docs slatejs org/concepts/11 typescript 0 60 — 24 novembre 2020 dernière minute introduction de nouveaux types typescript personnalisables vous pouvez remplacer les types intégrés pour les étendre à votre propre modèle de domaine d'éditeur cependant, les modifications nécessaires pour rendre cela possible ont probablement entraîné des changements dans les contrats de type existants le useeditor hook a été renommé en useslatestatic cela a été fait pour mieux différencier entre le useslate hook et pour clarifier que la version statique ne se re rendra pas lorsque des changements se produisent 0 59 — 24 septembre 2020 il n'y avait aucun changement majeur ni nouvelle addition dans cette version 0 58 — 5 mai 2020 important les propriétés utilisateur sur les éléments et les textes ont maintenant un type inconnu au lieu de n'importe quel type auparavant, les clés définies par l'utilisateur de manière arbitraire sur le texte et élément avaient un type de n'importe quel type ce qui supprimait effectivement toute vérification de type potentielle sur ces propriétés maintenant, celles ci ont un type de inconnu afin que la vérification de type puisse être effectuée par les consommateurs de l'api lorsqu'ils appliquent leurs propres propriétés personnalisées aux textes et éléments 0 57 — 18 décembre 2019 important les commandes remplaçables vivent maintenant directement sur l'objet éditeur auparavant, le concept de commande était implémenté comme une interface qui était passée dans la fonction editor exec , permettant aux commandes "noyau" d'être remplacées en un seul endroit mais cela a introduit beaucoup d'indirection de type redux lors de l'implémentation de commandes personnalisées qui n'étaient pas nécessaires car elles ne sont jamais remplacées au lieu de cela, maintenant les actions de base qui peuvent être remplacées sont implémentées comme des fonctions individuelles sur l'éditeur (par exemple, editor inserttext ) et elles peuvent être remplacées comme n'importe quelle autre fonction (par exemple, isvoid ) auparavant, pour remplacer une commande, vous feriez const withplugin = editor => { const { exec } = editor editor exec = command => { if (command type === 'insert text') { const { text } = command if (mycustomlogic) { // return } } exec(command) } return editor } maintenant, vous remplaceriez la fonction spécifique directement const withplugin = editor => { const { inserttext } = editor editor inserttext = text => { if (mycustomlogic) { // return } inserttext(text) } return editor } vous ne devriez jamais avoir besoin d'appeler ces fonctions directement ! elles sont là pour que les plugins puissent y accéder, mais il existe des helpers de niveau supérieur que vous pouvez appeler chaque fois que vous devez réellement les invoquer lisez la suite… les transformations vivent maintenant dans un espace de noms séparé d'aides auparavant, les aides à la transformation du document et de la sélection étaient disponibles directement sur le éditeur interface comme éditeur mais ces aides sont assez de bas niveau, et ce n'est pas quelque chose que vous utiliseriez dans votre propre code tout le temps, généralement seulement à l'intérieur d'aides personnalisées spécifiques à vous pour faire de la place pour des commandes personnalisées de l'utilisateur, ces aides ont été déplacées vers un nouveau transformations espace de noms auparavant, vous écririez editor unwrapnodes(editor, ) maintenant, vous écririez transforms unwrapnodes(editor, ) le command interfaces ont été supprimés dans le cadre de ces changements, l'existant command , corecommand , historycommand , et reactcommand interfaces ont tous été supprimés vous n'avez plus besoin de définir ces "objets de commande", car vous pouvez simplement appeler les fonctions directement les plugins peuvent toujours définir leurs propres commandes remplaçables en étendant le editor interface avec de nouvelles fonctions le slate react plugin le fait avec insertdata et le slate history plugin le fait avec undo et redo nouveau les aides à l'action utilisateur vivent maintenant directement sur le editor interface celles ci remplacent les anciennes transforms aides qui ont été déplacées ces aides sont équivalentes aux actions utilisateur, et elles opèrent toujours sur la sélection existante certaines sont définies par le noyau, mais vous êtes susceptible de définir vos propres aides personnalisées qui sont spécifiques à votre domaine également par exemple, voici quelques unes des actions intégrées editor inserttext(editor, 'a string of text') editor deleteforward(editor) editor deletebackward(editor, { unit 'word' }) editor addmark(editor, 'bold', true) editor insertbreak(editor) chacune des anciennes "commandes de base" a un équivalent editor aide exposée maintenant cependant, vous pouvez facilement définir vos propres aides personnalisées et les placer dans un espace de noms également const myeditor = { editor, insertparagraph(editor) { }, toggleboldmark(editor) { }, formatlink(editor, url) { }, } tout ce qui a du sens pour votre cas d'utilisation spécifique ! 0 56 — 17 décembre 2019 dernière minute la format text commande est divisée en add mark et remove mark bien que l'objectif soit de garder le nombre de commandes dans le cœur au minimum, avoir cela comme une commande combinée rendait très difficile l'écriture de la logique qui voulait garantir d'ajouter ou de retirer une marque d'un nœud de texte maintenant, vous pouvez être assuré que la add mark commande n'ajoutera jamais que des propriétés personnalisées aux nœuds de texte, et la remove mark commande ne les supprimera jamais auparavant, vous écriviez editor exec({ type 'format text', properties { bold true }, }) maintenant, vous écririez if (isactive) { editor exec({ type 'remove mark', key 'bold' }) } else { editor exec({ type 'add mark', key 'bold', value true }) } 🤖 notez que le terme "mark" ne signifie pas ce qu'il signifiait dans 0 47 et avant cela signifie simplement un formatage qui est appliqué au niveau du texte—gras, italique, etc nous avons besoin d'un terme pour cela car c'est un modèle si courant dans les éditeurs de texte enrichi, et "mark" est souvent le terme utilisé par exemple, la \<mark> balise en html le node text helper a été renommé en node string cela a simplement été fait pour réduire la confusion entre "la chaîne de texte" et "les nœuds de texte" l'assistant retourne toujours simplement le contenu de chaîne concaténé d'un nœud 0 55 — 15 décembre 2019 en direct l' option match doit maintenant être une fonction auparavant, il y avait quelques abréviations, comme passer un objet simple ce comportement a été supprimé car il rendait plus difficile de comprendre exactement ce qui était apparié, cela compliquait le débogage et rendait difficile une bonne saisie maintenant, l' option match doit être une fonction qui reçoit l'objet node à apparier si vous utilisez typescript, et que la fonction que vous passez est un garde de type, cela sera pris en compte dans la valeur de retour ! auparavant, vous pourriez écrire editor nodes(editor, { at range, match 'text', }) editor nodes(editor, { at range, match { type 'paragraph' }, }) maintenant, vous écririez editor nodes(editor, { at range, match text istext, }) editor nodes(editor, { at range, match node => node type === 'paragraph', }) l' option mode est maintenant par défaut à 'le plus bas' auparavant, le défaut variait en fonction de l'endroit où il était utilisé dans le code maintenant, il est par défaut à 'le plus bas' partout, et vous pouvez toujours passer à 'le plus élevé' pour changer le comportement la seule exception est le editor nodes helper qui par défaut est à 'tous' car c'est le comportement attendu la plupart du temps le editor match helper a été renommé en editor above c'était juste pour clarifier comment il recherchait dans l'arbre—il examine tous les nœuds directement au dessus d'un emplacement dans le document les editor above/previous/next helpers prennent maintenant toutes les options dans un dictionnaire auparavant, leurs api ne correspondaient pas exactement à la editor nodes helper pour lequel elles sont des abréviations, mais ce n'est plus le cas le at , match et mode options sont toutes passées dans l'argument options auparavant, vous auriez utilisé editor previous(editor, path, n => text istext(n), { mode 'lowest', }) maintenant, vous utiliseriez editor previous(editor, { at path, match n => text istext(n), mode 'lowest', }) le editor elements et editor texts les helpers ont été supprimés ce sont des helpers de commodité simples qui étaient rarement utilisés vous pouvez maintenant obtenir la même chose en utilisant le editor nodes helper directement avec le match option par exemple editor nodes(editor, { at range, match element iselement, }) 0 54 — 12 décembre 2019 dernière minute le \<slate> gestionnaire onchange ne reçoit plus l'argument selection auparavant, il recevait (valeur, sélection) , maintenant il reçoit simplement (valeur) au lieu de cela, vous pouvez accéder à n'importe quelle propriété de l'éditeur directement (y compris la valeur comme editor children ) la convention valeur/onchange est fournie uniquement pour des cas d'utilisation liés aux formulaires qui l'attendent cela va de pair avec le changement sur la façon dont les propriétés supplémentaires sont "contrôlées" par défaut, elles sont non contrôlées, mais vous pouvez passer n'importe laquelle des autres propriétés de l'éditeur de niveau supérieur pour en prendre le contrôle le commande et corecommand interfaces ont été séparées auparavant, vous pouviez accéder à command iscorecommand , cependant maintenant cette aide vit directement sur l'interface de commande principale comme corecommand iscorecommand cela le rend plus symétrique avec les commandes de l'utilisateur les vérificateurs de commande ont été simplifiés auparavant, slate exposait des aides de vérification de commande comme command isinserttextcommand cependant, celles ci étaient verbeuses et pas utiles la plupart du temps au lieu de cela, vous pouvez maintenant vérifier corecommand iscorecommand et ensuite utiliser la propriété command type pour affiner davantage cela garde le cœur plus symétrique avec la façon dont l'utilisateur mettra en œuvre des commandes personnalisées nouveau le \<slate> composant est maintenant pseudo contrôlé il nécessite un value= prop à passer qui est contrôlé cependant, la sélection , marques , historique , ou toute autre prop n'ont pas besoin d'être contrôlées elles sont par défaut non contrôlées si votre cas d'utilisation nécessite de contrôler ces props supplémentaires, vous pouvez les passer et elles commenceront à être contrôlées à nouveau ce changement a été fait pour faciliter l'utilisation de slate, tout en permettant à l'état plus complexe d'être contrôlé par le cœur ou les plugins à l'avenir—un état dont les utilisateurs n'ont pas besoin de se soucier la plupart du temps l' éditeur a maintenant une propriété de marques cette propriété représente le formatage au niveau du texte qui sera appliqué au prochain caractère inséré c'est un comportement courant des éditeurs de texte enrichi, où appuyer sur un bouton gras avec une sélection réduite active le mode de formatage "gras", et ensuite taper un caractère devient gras cet état n'est pas stocké dans le document, mais est plutôt stocké comme une propriété supplémentaire sur l'éditeur lui même 0 53 — 10 décembre 2019 breaking le slate schema package a été supprimé ! cette décision a été prise parce qu'avec les nouveaux helpers sur le editor interface, et avec les changements à normalizenode dans la dernière version de slate, ajouter des contraintes en utilisant normalizenode conduit en réalité à un code plus maintenable que d'utiliser slate schema auparavant, il était nécessaire de garder les choses lisibles, mais cela entraînait toujours un coût élevé d'indirection et d'apprentissage d'apis supplémentaires tout ce que vous pouviez faire avec slate schema vous pouvez le faire avec normalizenode , et plus encore les fonctions de correspondance de nœuds reçoivent maintenant juste un nœud auparavant, elles recevaient un nodeentry tuple, qui consistait en \[nœud, chemin] cependant, maintenant elles ne reçoivent qu'un nœud argument, ce qui facilite l'écriture de helpers de vérification de nœuds ponctuels et leur passage directement en tant qu'arguments si vous devez garantir un chemin, recherchez d'abord le nœud quelques helpers inutiles ont été supprimés il y avait une poignée de helpers restants qui n'étaient utilisés nulle part dans la logique de base de slate, et il était très peu probable qu'ils soient utilisés dans l'espace utilisateur, donc ils ont été supprimés pour réduire la taille du bundle vous êtes toujours libre de les réimplémenter si vous en avez vraiment besoin la liste des helpers supprimés est editor ancestor node leplusproche node leplusloin range existe range estlistedeplages range estcartedeplages 0 52 — 5 décembre 2019 dernière minute le slate schema paquet exporte maintenant une usine auparavant, vous importiez le withschema fonction directement depuis le paquet, et vous passiez vos règles de schéma lorsque vous l'appeliez cependant, maintenant vous importez la defineschema usine à la place, qui prend vos règles de schéma et retourne une fonction de plugin personnalisée withschema de cette façon, vous pouvez toujours utiliser des helpers comme compose avec le plugin, tout en pré définissant vos règles personnalisées les propriétés de validation dans le schéma est maintenant exhaustive auparavant, une validation des propriétés vérifiait toutes les propriétés que vous définissiez, et laissait celles inconnues telles quelles cela rendait difficile d'être certain des propriétés qui se retrouveraient sur un nœud maintenant, toutes les propriétés non définies sont considérées comme invalides et utiliser un vide {} de validation garantirait qu'il n'y a pas de propriétés personnalisées du tout nouveau les feuilles de validation du schéma garantissent le formatage au niveau du texte vous pouvez l'utiliser depuis n'importe quel nœud d'élément supérieur dans l'arbre, pour garantir qu'il ne contient que certains types de formatage au niveau du texte sur ses nœuds de texte internes par exemple, vous pourriez l'utiliser pour garantir qu'un bloc de code n'autorise aucun de ses textes à être en gras ou en italique 0 51 — 5 décembre 2019 breaking l' interface mark a été supprimée ! auparavant, le formatage au niveau du texte était stocké dans un tableau de marques uniques maintenant, ce même formatage est stocké directement sur les nœuds de texte eux mêmes par exemple, au lieu de { text 'a line of text ', marks \[{ type 'bold' }], } vous avez maintenant { text 'a line of text ', bold true, } et les marques sont ajoutées et supprimées des nœuds de texte en utilisant le même editor setnodes transformation que vous utilisez pour basculer le formatage sur les nœuds de bloc et en ligne cela simplifie grandement les choses et rend le cœur de slate encore plus petit le \<slate> composant est maintenant un composant "contrôlé" cela rend les choses un peu plus react ish, et facilite la mise à jour de la valeur de l'éditeur lorsque de nouvelles données sont reçues après le rendu initial pour arriver au comportement précédent "non contrôlé", vous devrez l'implémenter dans l'espace utilisateur en utilisant les hooks intégrés de react alors qu'auparavant vous feriez \<slate defaultvalue={initialvalue}> \</slate> maintenant, vous devez gérer la valeur et la sélection vous même, comme const \[value, setvalue] = usestate(initialvalue) const \[selection, setselection] = usestate(null) \<slate value={value} selection={selection} onchange={(value, selection) => { setvalue(value) setselection(selection) }} \> \</slate> 0 50 — 27 novembre 2019 dernière minute une refonte complète la base de code de slate a subi une refonte complète et de nombreux éléments de son architecture de base ont été reconsidérés depuis le début il y a beaucoup de changements nous recommandons de relire la https //docs slatejs org/walkthroughs et https //docs slatejs org/concepts pour avoir une idée de tout ce qui a changé ainsi que le https //github com/ianstormtaylor/slate/tree/71ff94c8d866a3ad9582ec4b84258d99d508fd70/site/examples/readme md pour comprendre les changements ainsi que le https //docs slatejs org/concepts/xx migrating pour ce qui est des changements majeurs ⚠ avertissement les changements à partir de ce point se réfèrent à l'ancienne architecture de slate, basée sur immutable js et sans typescript beaucoup de choses sont différentes dans l'ancienne architecture et peuvent ne pas s'appliquer à la nouvelle 0 47 — 8 mai 2019 nouveau présentation de la annotation modèle cela ressemble beaucoup à ce qui était stocké dans value decorations , sauf qu'ils contiennent également une "clé" unique pour être identifiés ils peuvent être utilisés pour des choses comme des commentaires, des suggestions, des curseurs collaboratifs, etc { object 'annotation', key string, type string, data map, anchor point, focus point, } il y a trois nouvelles annotation opérations l'ensemble des opérations comprend maintenant add annotation , remove annotation et set annotation ils sont similaires aux mark opérations existantes présentation des méthodes de modèle "itérable" cela introduit plusieurs méthodes produisant des itérables sur l' élément interface, qui document , bloc et en ligne implémentent tous il existe des itérables pour parcourir l'ensemble de l'arbre element blocks(options) element descendants(options) element inlines(options) element texts(options) element ancestors(path, options) element siblings(path, options) vous pouvez les utiliser tout comme les itérables javascript natifs par exemple, vous pouvez parcourir les nœuds de texte après un nœud spécifique for (const next of document texts({ path start path })) { const \[node, path] = next // do something with the text node or its path } ou vous pouvez parcourir tous les blocs "feuille" for (const \[block] of document blocks({ onlyleaves true })) { // } et parce que ces itérations utilisent des boucles for/of natives, vous pouvez facilement interrompre ou retourner directement des boucles—une expérience de développement bien plus agréable que de se souvenir de retourner faux cas d'urgence la value decorations propriété est maintenant value annotations suite à la séparation des décorations en annotations, cette propriété a également été renommée elles doivent maintenant contenir des clés uniques, car elles sont stockées sous forme de map au lieu d'une liste cela permet des mises à jour beaucoup plus performantes le décoration modèle n'a plus de marque propriété auparavant, un vrai marque objet était utilisé comme propriété sur les décorations, mais maintenant les type et données sont des propriétés de première classe à la place { object 'decoration', type string, data map, anchor point, focus point, } 0 46 — 1er mai 2019 dernière minute les opérations de marque n'ont plus décalage ou longueur propriétés puisque les nœuds de texte contiennent désormais un ensemble unique de marques, il n'aurait pas de sens qu'une seule opération liée à une marque entraîne une séparation des nœuds au lieu de cela, lorsqu'une marque est ajoutée à seulement une partie d'un nœud de texte, cela entraînera une opération split node ainsi qu'une opération add mark opération les opérations de texte n'ont plus de marques propriété auparavant, elle était utilisée pour ajouter du texte avec un ensemble spécifique de marques cependant, cela n'est plus nécessaire, et lorsque du texte est ajouté avec des marques, cela entraînera une opération insert text ainsi qu'une opération add mark opération utiliser text create ou text createlist avec un feuilles propriété générera une erreur maintenant que les nœuds de texte n'ont plus de feuilles, vous devrez passer la chaîne de texte et marques directement lors de la création d'un nouveau nœud de texte (cependant, vous pouvez toujours créer des valeurs entières en utilisant value create d'une manière rétrocompatible pour plus de commodité lors de la migration ) // this works, although deprecated, which is the common case value create(oldvaluejson) // but this will error! text create(oldtextjson) value tojson renvoie le nouveau format de modèle de données, sans feuilles bien que value fromjson et value create permettent l'ancien format en mode déprécié, appeler value tojson renverra le nouveau format de données si vous avez encore besoin de l'ancien, vous devrez itérer l'arbre du document en convertissant vous même les nœuds de texte les méthodes de mutation de bas niveau value et node ont changé ces changements suivent les modifications de la signature des opérations, puisque les méthodes prennent les mêmes arguments que les opérations elles mêmes par exemple // previously value addmark(path, offset, length, mark) // is now value addmark(path, mark) ce sont des méthodes de bas niveau, donc ce changement ne devrait pas affecter la majorité des cas d'utilisation déprécié initialiser des éditeurs avec text des nœuds avec une propriété de feuilles est déprécié dans cette nouvelle version de slate, créer une nouvelle valeur avec value create avec l'ancien modèle de données de feuilles est toujours autorisé pour des raisons de commodité lors de la migration, mais cela sera supprimé dans une version à venir (cependant, utiliser le bas niveau text create générera une erreur ! ) // this works, although deprecated, which is the common case value create(oldvaluejson) // but this will error! text create(oldtextjson) 0 45 — 2 avril 2019 dernière minute quelques propriétés de l'opération ont changé dans un effort pour standardiser et rationaliser les opérations, leurs propriétés ont changé cela ne affectera pas 90 % des cas d'utilisation, puisque les opérations sont généralement des préoccupations de bas niveau cependant, si vous utilisez une transformation opérationnelle ou d'autres parties de bas niveau de slate, cela peut vous affecter la valeur , sélection , nœud , et marque les propriétés—qui contenaient des références aux objets immutable js—ont toutes été supprimées à leur place, nous avons standardisé une propriétés et nouvellespropriétés paire cela réduira considérablement la taille des opérations stockées en mémoire et facilitera leur gestion lorsqu'elles sont sérialisées également 0 44 — 8 novembre 2018 nouveau présentation du child min invalid et child max invalid erreurs de schéma ces nouvelles erreurs de schéma correspondent directement aux mix et max définitions de règles de schéma, et facilitent la détermination de ce que votre logique de normalisation doit faire pour corriger le document ajout de nouvelles méthodes de récupération de nœuds il existe trois nouvelles méthodes pour la récupération de nœuds la première est getnodesatrange qui récupérera tous les nœuds dans l'arbre dans une plage donnée et les deux suivantes sont getrootblocksatrange et getrootinlinesatrange pour récupérer les blocs ou inlines les plus hauts dans une plage donnée cela devrait être utile pour définir votre propre logique de commande cas d'urgence erreurs de schéma pour min et max les règles ont changé auparavant, elles entraînaient des erreurs de child required , child object invalid , child type invalid et child unknown maintenant que nous avons les nouvelles child min invalid et child max invalid erreurs, ces règles de schéma les retourneront à la place, ce qui facilitera beaucoup la détermination de la règle exacte qui cause une erreur de schéma déprécié le getblocksatrange et getinlinesatrange méthodes ont été renommées pour clarifier la confusion sur les blocs et inlines récupérés en cas de nesting, ces deux méthodes ont été renommées en getleafblocksatrange et getleafinlinesatrange pour clarifier qu'elles récupèrent les nœuds les plus bas et maintenant, il y a deux méthodes supplémentaires appelées getrootblocksatrange et getrootinlinesatrange pour les cas où vous voulez les nœuds les plus hauts à la place 0 43 — 27 octobre 2018 nouveau le editor command et editor query méthodes peuvent prendre des fonctions auparavant, elles n'acceptaient qu'une chaîne de type et recherchaient la commande ou la requête par type maintenant, elles acceptent également une fonction personnalisée cela est utile pour les auteurs de plugins, qui souhaitent accepter une "option de commande", car cela donne aux utilisateurs plus de flexibilité pour écrire des commandes ou des requêtes ponctuelles par exemple, un plugin pourrait recevoir soit hotkey({ hotkey 'cmd+b', command 'addboldmark', }) ou une fonction de commande personnalisée hotkey({ hotkey 'cmd+b', command editor => editor addboldmark() movetoend(), }) dernière nouvelle le changement objet a été supprimé le changement objet tel que nous le connaissions précédemment a été supprimé, et tous ses comportements ont été intégrés dans le contrôleur de l'éditeur cela inclut les commandes et méthodes de requêtes de niveau supérieur, ainsi que des méthodes comme applyoperation et normalize tous les endroits qui recevaient auparavant changement reçoivent maintenant éditeur , ce qui est équivalent à l'api les changements sont maintenant envoyés à onchange de manière asynchrone auparavant, cela se faisait de manière synchrone, ce qui entraînait des conditions de concurrence étranges dans les environnements react maintenant, ils seront toujours envoyés de manière asynchrone, tout comme setstate le normalize et validate signatures des middleware ont changé ! auparavant, le normalize et validate middleware était passé (node, next) cependant, maintenant, pour la cohérence avec les autres middleware, ils sont tous passés (node, editor, next) de cette façon, tous les middleware reçoivent toujours éditeur et next comme leurs deux derniers arguments le éditeur event méthode a été supprimée auparavant, c'est ce que vous utiliseriez lors de l'écriture de tests pour simuler des événements déclenchés—qui étaient légèrement différents des autres middleware avec la simplification de l'éditeur et des signatures de middleware nouvellement cohérentes, vous pouvez maintenant utiliser éditeur run directement pour simuler des événements editor run('onkeydown', { key 'tab', }) déprécié le éditeur change méthode est dépréciée avec la suppression de l' objet change , il n'est plus nécessaire de créer les petites fermetures avec éditeur change() au lieu de cela, vous pouvez directement invoquer des commandes sur l'éditeur en série, et tous les changements seront émis de manière asynchrone au prochain tick editor inserttext('word') movefocusforward(10) addmark('bold') le applyoperations méthode est obsolète au lieu de cela, vous pouvez boucler un ensemble d'opérations et appliquer chacune en utilisant applyoperation cela vise à réduire le nombre de méthodes exposées sur l' éditeur pour le garder plus simple le change call méthode est obsolète auparavant, cela était utilisé pour appeler une fonction unique en tant que méthode de changement maintenant, ce comportement est équivalent à appeler editor command(fn) à la place 0 42 — 9 octobre 2018 nouveau présentation du éditeur contrôleur auparavant, il y avait un vague éditeur concept, qui était le composant react lui même cela était utile, mais parce qu'il était étroitement couplé à react et au navigateur, il ne se prêtait pas bien aux cas d'utilisation non liés au navigateur cela signifiait que la ligne entre "modèle" et "contrôleur/vue" était floue, et certains concepts vivaient aux deux endroits à la fois, de manière incohérente un nouveau éditeur contrôleur rend maintenant cette relation claire il emprunte beaucoup de ses comportements au composant react <éditeur> composant et le composant instancie en fait son propre éditeur javascript simple en coulisses pour déléguer le travail ce nouveau concept alimente beaucoup de la réflexion dans cette nouvelle version, débloquant de nombreux changements qui apportent une séparation plus claire des responsabilités à slate il nous permet de créer des éditeurs dans n'importe quel environnement, ce qui facilite les cas d'utilisation côté serveur, apporte une parité aux tests, et nous ouvre même à la prise en charge d'autres couches de vue comme react native ou vue js à l'avenir il a une api familière, basée sur le concept d' éditeur const editor = new editor({ plugins, value, onchange }) editor change(change => { }) cependant, il introduit également des méthodes impératives pour faciliter les tests editor run('rendernode', props) editor event('onkeydown', event) editor command('addmark', 'bold') editor query('isvoid', node) je suis très excité à ce sujet, j'espère que cela vous plaira ! introduction du concept de "commandes" auparavant, les "méthodes de changement" étaient traitées de manière privilégiée, mais les plugins n'avaient pas de moyen facile d'ajouter leurs propres méthodes de changement réutilisables ailleurs et ils n'avaient aucun moyen de remplacer la logique intégrée pour certaines commandes, par exemple splitblock ou inserttext cependant, maintenant tout cela est personnalisable par des plugins, le plugin slate de base fournissant toutes les commandes par défaut précédentes const plugin = { commands { wrapquote(change) { change wrapblock('quote') }, }, } ces commandes sont alors directement disponibles sur les objets change , qui sont maintenant spécifiques à l'éditeur change wrapquote() cela vous permet de définir toutes vos commandes dans un seul endroit facilement testable et ensuite, les plugins "comportementaux" peuvent simplement prendre les noms de commande comme options, afin que vous ayez un contrôle total sur la logique qu'ils déclenchent introduction du concept de "requêtes" de manière similaire aux commandes, les requêtes permettent aux plugins de définir des comportements spécifiques pour lesquels l'éditeur peut être interrogé de manière réutilisable, à utiliser lors du rendu des boutons, ou de la décision sur les comportements des commandes, etc par exemple, vous pourriez définir une getactivelist requête const plugin = { queries { getactivelist(editor) {}, }, } et ensuite pouvoir réutiliser cette logique facilement à différents endroits de votre code, ou passer le nom de la requête à un plugin qui peut utiliser votre logique personnalisée const list = change getactivelist() if (list) { } else { } pris ensemble, les commandes et les requêtes offrent une meilleure façon pour les plugins de gérer leurs interdépendances ils peuvent prendre des noms de commande ou de requête comme options pour changer leurs comportements, ou ils peuvent exporter de nouvelles commandes et requêtes que vous pouvez réutiliser dans votre code la pile de middleware est maintenant différable avec l'introduction du contrôleur éditeur, la pile de middleware dans slate a également été mise à jour chaque middleware reçoit maintenant une fonction (similaire à express ou koa) qui vous permet de choisir si vous souhaitez itérer la pile ou non // previously, you'd return `undefined` to continue function onkeydown(event, editor, next) { if (event key !== 'enter') return } // now, you call `next()` to continue function onkeydown(event, editor, next) { if (event key !== 'enter') return next() } bien que cela puisse sembler peu pratique, cela ouvre un tout nouveau comportement, qui consiste à différer aux plugins plus tard dans la pile pour voir s'ils "gèrent" un cas spécifique, et si ce n'est pas le cas, le gérer vous même function onkeydown(event, editor, next) { if (event key === 'enter') { const handled = next() if (handled) return handled // otherwise, handle `enter` yourself } } voici comment toute la logique de base dans slate react est maintenant implémentée, éliminant le besoin d'un plugin "avant" et d'un plugin "après" qui dupliquent la logique sous le capot, le schéma , commandes et requêtes sont tous implémentés en tant que plugins qui attachent également divers middleware par exemple, les commandes sont traitées à l'aide du middleware oncommand sous le capot const plugin = { oncommand(command, editor, next) { } } cela vous permet d'écouter réellement toutes les commandes et de remplacer des comportements individuels si vous choisissez de le faire, sans avoir à remplacer la commande elle même c'est une fonctionnalité très avancée, dont la plupart des gens n'auront pas besoin, mais elle montre la flexibilité offerte par la migration de toute la logique interne personnalisée précédente pour être basée sur la nouvelle pile de middleware les plugins peuvent maintenant être définis dans des tableaux imbriqués c'est un petit ajout, mais cela signifie que vous n'avez plus besoin de différencier entre des plugins individuels et plusieurs plugins dans un tableau cela permet aux plugins d'être plus facilement composés à partir de plusieurs autres plugins eux mêmes, sans que l'utilisateur final ait à changer la façon dont il les utilise petit, mais encourage un peu plus la réutilisation déprécié le slate simulator est déprécié auparavant, cela était utilisé comme un pseudo contrôleur à des fins de test cependant, maintenant avec le nouveau éditeur en tant que concept de première classe, tout ce que le simulateur pouvait faire peut maintenant être fait directement dans la bibliothèque cela devrait rendre les tests dans des environnements non navigateur beaucoup plus faciles à réaliser brisant la valeur l'objet n'est plus lié aux changements auparavant, vous pouviez créer un nouveau changement en appelant value change() et récupérer une nouvelle valeur avec la ré architecture pour découpler correctement le schéma, les commandes, les requêtes et les plugins des modèles de données de base de slate, cela n'est plus possible au lieu de cela, les changements sont toujours créés via une éditeur instance, où ces concepts résident // instead of const { value } = this state const change = value change() this onchange(change) // you now would do this editor change(change => { const { value } = change }) parfois, cela signifie que vous devrez stocker le ref de l' éditeur pour pouvoir accéder à sa editor change méthode dans vos composants react supprimez le stack "modèle", au profit du nouveau éditeur auparavant, il y avait un pseudo modèle appelé le stack qui était très bas niveau, et pas vraiment un modèle ce concept a maintenant été intégré dans le nouveau éditeur contrôleur, qui peut être utilisé dans n'importe quel environnement car c'est juste du javascript pur il n'y avait presque pas besoin d'utiliser directement une stack instance auparavant, donc ce changement ne devrait affecter presque personne retirez le schéma "modèle", au profit du nouveau éditeur auparavant, il y avait un autre pseudo modèle appelé le schéma , qui était utilisé pour contenir la logique de validation toutes les mêmes fonctionnalités de validation sont toujours disponibles, mais l'ancien schéma modèle est maintenant intégré dans le éditeur contrôleur également, sous la forme d'un schemaplugin qui n'est pas exposé retirez le schema isvoid et schema isatomic au profit des requêtes auparavant, ces deux méthodes étaient utilisées pour interroger le schéma sur le comportement d'un nœud ou décoration maintenant, ces mêmes requêtes sont possibles en utilisant le concept de "requêtes", et sont disponibles directement sur l'objet changement if (change isvoid(node)) { } la pile de middleware doit maintenant être explicitement poursuivie, en utilisant next auparavant, retourner undefined d'un middleware poursuivrait (généralement) la pile vers le middleware suivant maintenant, avec le middleware prenant un next argument de fonction, vous devez décider explicitement de continuer la pile en appelant next() vous même supprimez le modèle d'historique , au profit des commandes auparavant, il y avait un modèle d'historique qui stockait les piles d'annulation/rétablissement, et gérait l'enregistrement de nouvelles opérations dans ces piles toute cette logique a été intégrée dans le nouveau concept de "commandes", et les piles d'annulation/rétablissement résident désormais dans value data cela a l'avantage de permettre au comportement d'historique d'être complètement remplaçable par des plugins de l'utilisateur, ce qui n'était pas une tâche facile à gérer auparavant les valeurs ne peuvent plus être normalisées à la création avec le découplage du modèle de données et de la couche de plugin, les règles de schéma ne sont plus disponibles à l'intérieur du modèle de valeur cela signifie que vous ne pouvez plus recevoir une valeur "normalisée" sans avoir accès à l' éditeur et à ses plugins // while previously you could attach a `schema` to a value const normalized = value create({ , schema }) // now you'd need to do that with the `editor` const value = value create({ }) const editor = new editor({ value, plugins \[{ schema }] }) const normalized = editor value bien que cela semble peu pratique, cela rend les frontières dans l'api beaucoup plus claires et maintient les concepts immuables et mutables séparés cet exemple de code spécifique devient plus long, mais les complexités ailleurs dans la bibliothèque sont supprimées le changement classe n'est plus exportée les changements sont maintenant spécifiques à l'éditeur, donc l'exportation de la changement classe n'a plus de sens au lieu de cela, vous pouvez utiliser le editor change() api pour recevoir un nouvel objet de changement avec les commandes et requêtes spécifiques aux plugins de votre éditeur le getclosestvoid , getdecorations et hasvoidparent méthode prend maintenant un éditeur auparavant, ces node méthodes prenaient un schéma argument, mais cela a été remplacé par le nouveau éditeur contrôleur maintenant que le schéma modèle a été supprimé 0 41 — 21 septembre 2018 déprécié le withoutnormalization helper a été renommé en withoutnormalizing cela vise à rester cohérent avec les nouveaux helpers pour withoutsaving et withoutmerging dernière minute le concept de "flags d'opération" a été supprimé c'était un concept déroutant qui a été mis en œuvre de plusieurs manières différentes et a conduit à une logique autour de la normalisation, de l'enregistrement et des opérations de fusion plus complexe qu'elle ne devait l'être ces flags ont été remplacés par trois fonctions d'aide plus simples withoutnormalizing , withoutsaving et withoutmerging change withoutnormalizing(() => { nodes foreach(node => change removenodebykey(node key)) }) change withoutsaving(() => { change setvalue({ decorations }) }) cela signifie que vous n'utilisez plus le { normalize false } ou { save false } options comme arguments pour les méthodes de changement individuelles, et utilisez plutôt ces nouvelles méthodes d'assistance pour appliquer ces comportements à des groupes de changements à la fois les méthodes de changement "normalize" ont été supprimées auparavant, il y avait une poignée de différentes méthodes de changement de normalisation comme normalizenodebypath , normalizeparentbykey , etc celles ci étaient déroutantes car elles mettaient la responsabilité sur l'implémenteur de savoir exactement quels nœuds devaient être normalisés elles ont été supprimées, et les implémenteurs n'ont plus jamais besoin de s'inquiéter des nœuds spécifiques à normaliser, car slate s'en occupera pour eux les méthodes internes refindnode et refindpath ont été supprimées celles ci n'auraient jamais dû être exposées en premier lieu, et ne sont plus présentes sur l' element interface celles ci n'étaient utilisées qu'en interne pendant le processus de normalisation 0 40 — 22 août 2018 cas de rupture supprimez tous les chemins de code précédemment obsolètes cela aide à réduire une partie de la complexité dans slate en n'ayant plus à gérer ces chemins de code et cela aide à réduire la taille des fichiers lors de la mise à niveau, il est très recommandé de mettre à niveau d'abord vers la version précédente et de s'assurer qu'aucun avertissement de dépréciation n'est enregistré, puis de mettre à niveau vers cette version 0 39 — 22 août 2018 nouveau présentation de la plage modèle et interface auparavant, le concept de "plage" était utilisé à plusieurs endroits différents, pour la sélection, pour les décorations, et pour agir sur des plages du document cela fonctionnait correctement, mais cela cachait le système sous jacent qui est que plage est vraiment une interface que d'autres modèles peuvent choisir d'implémenter maintenant, nous utilisons toujours la plage modèle pour référencer des parties du document, mais il peut également être implémenté par d'autres modèles qui ont besoin d'attacher plus de signification sémantique présentation de la décoration et sélection modèles ces deux nouveaux modèles implémentent tous deux la nouvelle plage interface auparavant, ils devaient mal utiliser le plage modèle lui même avec des sémantiques ajoutées cela clarifie simplement une partie de la confusion autour des propriétés qui se chevauchent, et nous permet d'ajouter encore plus de méthodes et de propriétés spécifiques au domaine à l'avenir sans problème dernière minute les décorations ont changé ! auparavant, les décorations s'appuyaient sur le modèle existant, utilisant la propriété marques et introduisant leur propre isatomic propriété cependant, elles ont maintenant été séparées dans leur propre modèle de décoration avec une seule marque et avec la isatomic propriété contrôlée par le schéma ce qui auparavant aurait ressemblé à range create({ anchor { }, focus { }, marks \[{ type 'highlight' }], isatomic true, }) est maintenant decoration create({ anchor { }, focus { }, mark { type 'highlight' }, }) chaque décoration correspond à un seul marque objet et l'atomicité de la marque est contrôlée dans le schéma à la place, par exemple const schema = { marks { highlight { isatomic true, }, }, } le modèle de plage a réduit la sémantique auparavant, puisque toutes les décorations et sélections étaient des plages, vous pouviez créer des plages avec un isfocused , isatomic ou marques propriétés maintenant, les plages sont beaucoup plus simples, offrant seulement un ancre et un focus , et peuvent être étendues par d'autres modèles implémentant l'interface de plage cependant, cela signifie que l'utilisation de range create ou document createrange pourrait ne plus être ce que vous voulez par exemple, pour créer une nouvelle sélection, vous utilisiez const selection = document createrange({ isfocused true, anchor { }, focus { }, }) mais maintenant, vous devrez utiliser document createselection à la place const selection = document createselection({ isfocused true, anchor { }, focus { }, }) la value decorations propriété n'est plus nullable auparavant, lorsque aucune décoration n'était appliquée à la valeur, la décoration propriété était définie sur null maintenant, ce sera une liste vide, afin que l'interface soit plus cohérente déprécié le node createchildren méthode statique est obsolète c'était juste un alias pour node createlist et n'était pas nécessaire vous pouvez utiliser node createlist à l'avenir pour le même effet la renderportal propriété des plugins est obsolète cela permet à slate react d'être légèrement plus léger, car ce comportement peut être géré dans react 16 avec le nouveau \<react fragment> en utilisant la rendereditor propriété à la place, d'une manière qui offre plus de contrôle sur le comportement du portail la data propriété des plugins est obsolète cette propriété n'était pas bien conçue et contournait le principe fondamental selon lequel tous les changements apportés à la value l'objet passera par des opérations à l'intérieur des change objets il était principalement utilisé pour l'état de la couche de vue qui devrait être géré avec des conventions spécifiques à react pour la gestion de l'état à la place 0 38 — 21 août 2018 obsolete node isvoid l'accès est obsolète auparavant, la "voidness" d'un nœud était codée en dur dans le modèle de données bientôt, elle sera déterminée à l'exécution en fonction du schéma de votre éditeur cette dépréciation garantit simplement que vous n'utilisez pas la node isvoid propriété qui ne fonctionnera pas dans les futures versions ce qui aurait été auparavant if (node isvoid) { } deviens maintenant if (schema isvoid(node)) { } cela nécessite que vous ayez une référence à l' schéma objet, qui peut être accessible comme value schema value isfocused/isblurred et value hasundos/hasredos sont obsolètes ces propriétés sont facilement accessibles via value selection et value history à la place, et sont maintenant obsolètes pour réduire la complexité et le nombre de façons différentes de faire les choses 0 37 — 3 août 2018 nouveau présentation du point modèle les plages sont maintenant constituées de deux point modèles—un ancre et un focus —au lieu d'avoir les propriétés définies directement sur la plage elle même cela rend le concept de "point" de première classe dans slate et de meilleures api peuvent être construites autour des objets point point create({ key 'a', path \[0, 0], offset 31, }) ces points sont exposés sur les plages objets via l' ancre , focus , début et fin propriétés const { anchor, focus } = range change removenodebykey(anchor key) ceci remplace les précédents anchorkey , anchoroffset , etc propriétés document createrange crée une plage relative auparavant, vous deviez utiliser range create et vous assurer que vous passiez des arguments valides, et vous assurer que vous "normalisiez" la plage pour synchroniser ses clés et chemins ce n'est plus le cas, puisque le createrange méthode le fera pour vous const range = document createrange({ anchor { key 'a', offset 1, }, focus { key 'a', offset 4, }, }) cela garantira automatiquement que la plage référence des nœuds de texte feuille, et que ses anchor et focus chemins sont définis document createpoint crée un point relatif tout comme la createrange méthode, createpoint créera un point qui est garanti d'être relatif au document lui même c'est souvent beaucoup plus facile que d'utiliser point create directement const anchor = document createpoint({ key 'a', offset 1, }) cas critique le range focus méthode a été supprimée (pas change focus !) cela était nécessaire pour faire place à la nouvelle range focus propriété point en général, cela aurait été fait de manière compatible avec la migration comme le reste des changements de méthode dans cette version, mais c'était une exception cependant, le change focus() méthode est toujours disponible et fonctionne comme prévu range set et range merge sont dangereux si vous utilisiez auparavant les méthodes immutable js de très bas niveau range set ou range merge avec l'une des propriétés de plages maintenant supprimées, ces invocations échoueront au lieu de cela, vous devriez utiliser les range set helpers à l'avenir qui peuvent être migrés avec des avertissements de dépréciation au lieu d'échouer complètement le offset propriété des points par défaut à null auparavant, elle par défaut à 0 mais cela pouvait être déroutant car cela ne faisait aucune distinction entre un offset "défini" ou "non défini" maintenant, ils par défaut à null à la place cela ne devrait pas vraiment affecter l'utilisation réelle de slate la range tojson() structure a changé avec l'introduction des points, la plage renvoie maintenant ses anchor et focus propriétés sous forme d'objets json de points imbriqués au lieu de directement comme propriétés par exemple { "object" "range", "anchor" { "object" "point", "key" "a", "offset" 1, "path" \[0, 0] }, "focus" { "object" "point", "key" "a", "offset" 3, "path" \[0, 0] }, "isatomic" false, "isfocused" false, "marks" \[] } déprécié les shorts basés sur la sélection sur valeur ont été dépréciés auparavant, vous pouviez accéder à des éléments comme anchorkey , startoffset et iscollapsed directement sur valeur objets cela entraîne une duplication supplémentaire qui est difficile à maintenir dans le temps, et difficile à comprendre pour les nouveaux venus, sans grand bénéfice toutes ces propriétés sont dépréciées et doivent être accessibles sur le value selection objet directement à la place les méthodes de plage ont été standardisées, avec de nombreuses dépréciations les méthodes sur range objets avaient considérablement augmenté en taille beaucoup d'entre elles n'étaient pas nommées de manière cohérente, ou se chevauchaient de manière inutile avec l'introduction de point objets, beaucoup de ces méthodes pouvaient être simplifiées et leur logique déléguée directement aux points toutes ces méthodes restent disponibles mais généreront des avertissements de dépréciation, facilitant ainsi la mise à niveau il y a de très bonnes chances que vous n'utilisiez qu'une poignée d'entre elles dans votre code quoi qu'il en soit, toutes généreront des avertissements pour un exemple de migration, voir https //github com/ianstormtaylor/slate/pull/2035/commits/1bc560ab6242bc015c9f6d3bd20086f18849f8b7 voici une liste complète des méthodes et propriétés nouvellement obsolètes, ainsi que leur nouvelle alternative si elle existe anchorkey > anchor key anchoroffset > anchor offset anchorpath > anchor path blur > setisfocused collapseto > moveto collapsetoanchor > movetoanchor collapsetoend > movetoend collapsetoendof > movetoendofnode collapsetofocus > movetofocus collapsetostart > movetostart collapsetostartof > movetostartofnode deselect > range create endkey > end key endoffset > end offset endpath > end path extend > movefocus extendto > movefocusto extendtoendof > movefocustoendofnode extendtostartof > movefocustostartofnode focuskey > focus key focusoffset > focus offset focuspath > focus path hasanchoratendof > anchor isatendofnode hasanchoratstartof > anchor isatstartofnode hasanchorbetween > hasanchorin > anchor isinnode hasedgeatendof > anchor isatendofnode || focus isatendofnode hasedgeatstartof > anchor isatstartofnode || focus isatstartofnode hasedgebetween > hasedgein > anchor isinnode || focus isinnode hasendatendof > end isatendofnode hasendatstartof > end isatendofnode hasendbetween > hasendin > end isinnode hasfocusatendof > focus isatendofnode hasfocusatstartof > focus isatstartofnode hasfocusbetween > hasfocusin > focus isinnode hasstartatendof > start isatendofnode hasstartatstartof > start isatstartofnode hasstartbetween > hasstartin > start isinnode isatendof > iscollapsed && anchor isatendofnode isatstartof > iscollapsed && anchor isatstartofnode move > moveforward/backward moveanchor > moveanchorforward/backward moveanchoroffsetto > moveanchorto moveanchoroffsetto > moveanchorto moveanchortoendof > moveanchortoendofnode moveanchortostartof > moveanchortostartofnode moveend > moveendforward/backward moveendoffsetto > moveendto movefocus > movefocusforward/backward movefocusoffsetto > movefocusto movefocusoffsetto > movefocusto movefocustoendof > movefocustoendofnode movefocustostartof > movefocustostartofnode moveoffsetsto > moveanchorto && movefocusto movestart > movestartforward/backward movestartoffsetto > movestartto movetoendof > movetoendofnode movetorangeof > movetorangeofnode movetostartof > movetostartofnode startkey > start key startoffset > start offset startpath > start path les changements basés sur la sélection ont été standardisés, avec de nombreux éléments obsolètes de même que les dépréciations de la méthode changement qui traitaient des sélections beaucoup d'entre elles ont été renommées pour la cohérence, ou dépréciées lorsque des alternatives existaient tous ces méthodes restent disponibles mais généreront des avertissements de dépréciation, facilitant ainsi la mise à niveau il y a de très bonnes chances que vous n'utilisiez qu'une poignée de ces méthodes de changement dans votre code quoi qu'il en soit, toutes généreront des avertissements pour un exemple de migration, voir https //github com/ianstormtaylor/slate/pull/2035/commits/1bc560ab6242bc015c9f6d3bd20086f18849f8b7 voici une liste complète des méthodes nouvellement obsolètes et de leurs nouvelles alternatives, si elles existent collapsecharbackward > movebackward collapsecharforward > moveforward collapselinebackward > movetostartofblock collapselineforward > movetoendofblock collapseto > moveto collapsetoanchor > movetoanchor collapsetoend > movetoend collapsetoendof > movetoendofnode collapsetoendofblock > movetoendofblock collapsetoendofnextblock > movetoendofnextblock collapsetoendofnexttext > movetoendofnexttext collapsetoendofpreviousblock > movetoendofpreviousblock collapsetoendofprevioustext > movetoendofprevioustext collapsetofocus > movetofocus collapsetostart > movetostart collapsetostartof > movetostartofnode collapsetostartofblock > movetostartofblock collapsetostartofnextblock > movetostartofnextblock collapsetostartofnexttext > movetostartofnexttext collapsetostartofpreviousblock > movetostartofpreviousblock collapsetostartofprevioustext > movetostartofprevioustext extend > movefocusforward/backward extendcharbackward > movefocusbackward extendcharforward > movefocusforward extendlinebackward > movefocustostartofblock extendlineforward > movefocustoendofblock extendto > movefocusto extendtoendof > movefocustoendofnode extendtoendofblock > movefocustoendofblock extendtoendofnextblock > movefocustoendofnextblock extendtoendofnextinline > movefocustoendofnextinline extendtoendofnexttext > movefocustoendofnexttext extendtoendofpreviousblock > movefocustoendofpreviousblock extendtoendofpreviousinline > movefocustoendofpreviousinline extendtoendofprevioustext > movefocustoendofprevioustext extendtostartof > movefocustostartofnode extendtostartofblock > movefocustostartofblock extendtostartofnextblock > movefocustostartofnextblock extendtostartofnextinline > movefocustostartofnextinline extendtostartofnexttext > movefocustostartofnexttext extendtostartofpreviousblock > movefocustostartofpreviousblock extendtostartofpreviousinline > movefocustostartofpreviousinline extendtostartofprevioustext > movefocustostartofprevioustext move > moveforward/backward moveanchor > moveanchorforward/backward moveanchorcharbackward > moveanchorbackward moveanchorcharforward > moveanchorforward moveanchoroffsetto > moveanchorto moveanchortoendof > moveanchortoendofnode moveanchortostartof > moveanchortoendofnode movecharbackward > movebackward movecharforward > moveforward moveend > moveendforward/backward moveendcharbackward > moveendbackward moveendcharforward > moveendforward moveendoffsetto > moveendto movefocus > movefocusforward/backward movefocuscharbackward > movefocusbackward movefocuscharforward > movefocusforward movefocusoffsetto > movefocusto movefocustoendof > movefocustoendofnode movefocustostartof > movefocustoendofnode moveoffsetsto > moveanchorto/movefocusto movestart > movestartforward/backward movestartcharbackward > movestartbackward movestartcharforward > movestartforward movestartoffsetto > movestartto movetoendof > movetoendofnode movetorangeof > movetorangeofnode movetostartof > movetostartofnode selectall > movetorangeofdocument 0 36 — 27 juillet 2018 dernière minute les règles de schéma ont changé ! pour les rendre utilisables dans plus de cas (afin que vous n'ayez pas à descendre vers le plus lent validatenode/normalizenode fonction), la syntaxe de correspondance pour les règles de schéma a changé auparavant, plusieurs types/objets étaient exprimés comme { parent { types \['ordered list', 'unordered list'] }, } maintenant, il y a un nouveau match concept d'objet, qui ressemble à { parent { object 'block', type 'list' }, } les objets de correspondance peuvent être des objets, ou un tableau d'objets qui agit comme ou { parent \[{ type 'ordered list' }, { type 'unordered list' }], } de plus, les règles de schéma peuvent maintenant être définies à l'aide d'un schema rules tableau d'objets avec des propriétés de correspondance de premier niveau cela permet de faire correspondre des nœuds de manière qui était auparavant impossible par exemple { schema { rules \[{ // match all blocks, regardless of type! match { object 'block' }, text / /g, normalize () => { }, }] } } tous les raccourcis comme schema blocks et schema inlines sont toujours disponibles, et sont simplement réécrits dans la syntaxe plus flexible de règles en coulisses ces changements sont juste une petite façon de rendre slate plus flexible pour des cas d'utilisation avancés lorsque vous y êtes confrontés la règle de schéma normaliser les fonctions reçoivent maintenant slateerror objets auparavant, ils étaient appelés avec une signature de (changement, violation, contexte) ils sont maintenant appelés avec (changement, erreur) cette nouvelle erreur est un slateerror objet avec un error code et toutes les mêmes propriétés de contexte un normaliseur qui ressemblait auparavant à { normalize (change, violation, context) { if (violation === 'child type invalid') { const type = index === 0 ? 'title' 'paragraph' return change setnodebykey(context child key, type) } } } ressemblerait maintenant à { normalize (change, error) { if (error code === 'child type invalid') { const type = index === 0 ? 'title' 'paragraph' return change setnodebykey(error child key, type) } } } c'est juste une tentative de rendre le traitement des erreurs de normalisation légèrement plus idiomatique avec la façon dont les erreurs sont représentées dans la plupart des bibliothèques, afin de ne pas réinventer la roue inutilement 0 35 — 27 juillet 2018 nouveau plage objets suivent maintenant les chemins, en plus des clés auparavant, les plages ne stockaient que leurs points en tant que clés maintenant, les chemins et les clés sont utilisés, ce qui vous permet de choisir celui qui est le plus pratique ou le plus performant pour votre cas d'utilisation ils sont synchronisés par slate en arrière plan un nouvel ensemble de parchemin méthodes de changement ont été ajoutées tous les changements que vous pouviez auparavant effectuer avec un parclé changement sont maintenant également pris en charge avec un parchemin changement du même nom les changements basés sur le chemin sont souvent plus performants que ceux basés sur la clé les chemins sont maintenant de type liste https //facebook github io/immutable js/docs/#/list au lieu de tableau consultez la documentation de liste https //facebook github io/immutable js/docs/#/list pour ses différences avec le tableau ( obtenir méthode au lieu de l'indexation de tableau, taille au lieu de longueur , etc) dernière nouvelle interne mais public node les méthodes ont été modifiées il y avait une poignée de méthodes internes qui ne devraient pas être utilisées dans 99 % des implémentations de slate qui ont été mises à jour ou supprimées cela a été fait dans le processus de rationalisation de nombreuses node méthodes pour les rendre plus cohérentes et plus faciles à utiliser pour une liste de ceux affectés node assertpath a été changé il était auparavant nommé de manière confuse car l'équivalent node getpath faisait quelque chose de complètement différent vous devez maintenant utiliser node assertnode(path) si vous avez besoin de ce comportement node removedescendant a été supprimé il n'y a aucune raison pour que vous ayez dû l'utiliser, car c'était une méthode non documentée et inutilisée qui était restée d'une version précédente node updatenode , node insertnode , node removenode , node splitnode et node mergenode les méthodes de mutation ont été modifiées tous vos changements doivent être effectués avec des opérations, donc vous n'utilisiez probablement pas ces méthodes internes elles ont été modifiées en interne pour utiliser des chemins déprécié le setkeygenerator et resetkeygenerator aides sont dépréciées celles ci étaient auparavant utilisées pour changer la logique de génération de clés par défaut maintenant, vous pouvez utiliser l'équivalent keyutils setgenerator et keyutils resetgenerator aides à la place cela suit le nouveau modèle de regroupement des utilitaires connexes dans des espaces de noms uniques, comme c'est le cas avec le nouveau pathutils et textutils les méthodes node internes mais publiques ont été dépréciées il y avait une poignée de méthodes internes qui ne devraient pas être utilisées dans 99 % des implémentations de slate qui ont été dépréciées pour une liste de celles affectées node getkeys et node getkeysasarray ont été dépréciées si vous avez vraiment besoin de vérifier la présence d'une clé, utilisez le nouveau node getkeystopathsobject à la place node aredescendantssorted et node isinrange ont été dépréciées celles ci étaient utilisées pour vérifier si un nœud était dans une plage, mais cela peut maintenant être fait de manière plus performante et plus facilement avec des chemins node getnodeatpath et node getdescendantatpath ont été dépréciées celles ci n'étaient probablement utilisées par personne, mais si vous les utilisiez, vous pouvez utiliser les méthodes existantes node getnode et node getdescendant qui prennent maintenant soit des chemins soit des clés 0 34 — 14 juin 2018 nouveau les décorations peuvent maintenant être "atomiques" si vous définissez une décoration comme atomique, elle sera supprimée lorsqu'elle sera modifiée, empêchant son entrée dans un état "partiel", ce qui peut être utile pour certains cas d'utilisation dernière minute les nœuds de texte représentent maintenant leur contenu comme des "feuilles" auparavant, leur représentation immuable utilisait une instance individuelle de caractère pour chaque caractère maintenant, ils ont changé pour regrouper les caractères en feuille modèles, qui ressemblent davantage à la façon dont ils sont utilisés, et cela entraîne un grand nombre d'instances d'objets immuables en circulation pour la plupart des gens, cela ne devrait pas poser de problèmes, car il s'agit d'un aspect de bas niveau de slate obsolete le caractère modèle est obsolète bien que le concept de caractère soit encore dans le dépôt pour l'instant, il est obsolète et sera supprimé dans une future version tout ce qu'il résout peut être résolu avec des feuilles à la place 0 33 — 21 février 2018 dernière minute les nœuds vides ne prescrivent plus leur contenu textuel auparavant, les nœuds vides normalisaient automatiquement leur contenu textuel pour être un seul nœud de texte contenant ' ' une chaîne vide de contenu cette restriction a été supprimée, de sorte que les nœuds vides peuvent avoir un contenu arbitraire vous pouvez utiliser cela pour stocker des informations dans des nœuds vides d'une manière qui est plus cohérente avec les nœuds non vides déprécié le setblock méthode a été renommée en setblocks cela vise à rendre plus clair qu'elle opère sur n'importe quel des blocs actuels dans la sélection, pas seulement sur un seul bloc le setinline méthode a été renommée en setinlines pour la même raison que setblocks , pour être clair et rester cohérent 0 32 — 4 janvier 2018 brisant la propriété des objets slate a été renommée en objet cela vise à réduire la confusion sur la différence entre "kind" et "type" qui sont pratiquement des synonymes le nom "objet" a été choisi pour correspondre à l'api stripe, car cela semble être un choix sensé et se lit beaucoup mieux en parcourant le json toutes les raisons de normalisation contenant kind ont également été renommées auparavant, il y avait des chaînes de raison de normalisation comme child kind invalid ces types de chaînes ont été renommés en child object invalid pour rester cohérent 0 31 — 16 novembre 2017 nouveau ajouté un nouveau modèle d'opération ce modèle est utilisé pour stocker les opérations dans la pile d'historique, et (dé)serialize les opérations de manière cohérente pour les cas d'utilisation d'édition collaborative important les objets d'opération dans slate sont maintenant des enregistrements immuables auparavant, ils étaient des objets javascript natifs et mutables maintenant, il y a un nouveau modèle d'opération immuable dans slate, garantissant que toutes les données à l'intérieur des objets valeur sont immuables et cela permet une sérialisation facile des opérations en utilisant operation tojson() pour les envoyer entre les éditeurs cela ne devrait pas affecter la plupart des utilisateurs, sauf si vous comptez changer les valeurs des opérations de bas niveau de slate (les lire simplement est acceptable) les listes d'opération dans slate sont maintenant des listes immuables auparavant, elles étaient des tableaux javascript natifs et mutables maintenant, pour rester cohérent avec d'autres utilisations immuables, ce sont des listes immuables cela ne devrait pas affecter la plupart des utilisateurs 0 30 — 27 octobre 2017 important supprimer tous les chemins de code précédemment obsolètes cela aide à réduire une partie de la complexité dans slate en n'ayant plus à gérer ces chemins de code et cela aide à réduire la taille des fichiers lors de la mise à niveau, il est très recommandé de mettre à niveau d'abord vers la version précédente et de s'assurer qu'aucun avertissement de dépréciation n'est enregistré, puis de mettre à niveau vers cette version 0 29 — 27 octobre 2017 nouveau ajouté le nouveau valeur modèle pour remplacer état le nouveau modèle est exactement le même, mais avec un nouveau nom il y a aussi un modèle état exporté qui avertit lorsqu'il est utilisé, pour faciliter la migration dernière minute l' set state opération a été renommée set value cela ne devrait presque affecter personne, mais dans le cas où vous comptiez sur les types d'opérations de bas niveau, vous devrez mettre à jour cela obsolete le "state" a été renommé en "value" partout toutes les références actuelles sont maintenues en tant que dépréciations, donc vous devriez pouvoir mettre à niveau et voir des avertissements enregistrés au lieu d'être accueilli par un éditeur cassé cela vise à réduire la confusion entre le "state" de react et la valeur de l'éditeur de slate, et dans un effort pour imiter davantage les api dom natives 0 28 — 25 octobre 2017 nouveau état les objets ont maintenant une state schema propriété cette nouvelle propriété de schéma est utilisée pour normaliser automatiquement l'état à mesure qu'il change, selon le schéma actuel de l'éditeur cela rend la normalisation beaucoup plus facile dernière minute le schéma les objets dans slate ont changé ! auparavant, ils étaient l'endroit où vous pouviez définir des règles de normalisation, définir des règles de rendu et définir des règles de décoration cela était surchargé et rendait d'autres améliorations difficiles maintenant, le rendu et la décoration se font via les nouvelles fonctions de plugin ajoutées ( rendernode , rendermark , decoratenode ) et la validation se fait soit via la fonction de plugin de niveau inférieur validatenode , soit via le nouveau schéma objets le normalize méthodes de changement ne prennent plus un schéma argument auparavant, vous deviez maintenir une référence à votre schéma et la passer dans les méthodes de normalisation lorsque vous les appeliez puisque état les objets ont maintenant une state schema propriété, cela n'est plus nécessaire 0 27 — 14 octobre 2017 dernière minute le plage modèle s'appelle maintenant feuille cela permet de ne pas confondre avec le concept de "plages" qui est utilisé dans tout le code pour être synonyme de sélections par exemple, dans des méthodes comme getblocksatrange(selection) le text ranges propriété dans la représentation json est maintenant text leaves lorsque vous passez en json avec text ranges vous recevrez maintenant un avertissement de dépréciation dans la console en développement déprécié le sélection modèle s'appelle maintenant plage cela vise à clarifier ce qu'est vraiment une "sélection", à rendre de nombreuses autres méthodes qui agissent sur les "plages" plus sensées, et à paralléliser plus étroitement l'api dom native pour les sélections et les plages un objet de mock sélection est toujours exporté avec des méthodes statiques dépréciées, pour faciliter la transition vers la nouvelle api le text getranges() méthode est maintenant text getleaves() elle fonctionnera toujours, et elle renverra une liste de feuilles, mais vous verrez un avertissement de dépréciation dans la console en développement 0 26 — 13 octobre 2017 dernière minute le décorateur de la fonction des règles de schéma a changé auparavant, dans décorateur vous receviez un nœud de texte et le nœud correspondant, et vous deviez ajouter manuellement les marques que vous souhaitiez aux caractères du nœud de texte maintenant, les "décorations" ont changé pour être simplement des sélections d'objets avec des marques dans la selection marks propriété au lieu d'appliquer les marques vous même, vous renvoyez simplement des plages de sélection avec les marques à appliquer, et slate les appliquera en interne cela rend possible l'écriture de comportements de décoration beaucoup plus complexes consultez l'exemple revu de mise en surbrillance du code https //github com/ianstormtaylor/slate/blob/master/examples/code highlighting/index js et le nouveau mise en surbrillance de recherche https //github com/ianstormtaylor/slate/blob/master/examples/search highlighting/index js exemple pour voir cela en action le set data type d'opération a été remplacé par set state avec le nouveau state decorations propriété, il n'est pas logique d'avoir un nouveau type d'opération pour chaque propriété de état objets au lieu de cela, le nouveau set state opération imite de plus près les opérations existantes set mark et set node opérations déprécié nouveau vous pouvez maintenant définir des décorations basées sur des informations externes auparavant, la logique de "décoration" dans slate était toujours basée sur le texte d'un nœud et ne se redessinait que lorsque ce texte changeait maintenant, il y a une nouvelle state decorations propriété que vous pouvez définir via change setstate({ decorations }) vous pouvez l'utiliser pour ajouter des marques uniquement de présentation à des plages de texte arbitraires dans le document consultez le nouvel search highlighting https //github com/ianstormtaylor/slate/blob/master/examples/search highlighting/index js exemple pour voir cela en action le setdata méthode de changement a été remplacée par setstate auparavant, vous appeliez change setdata(data) mais à mesure que de nouvelles state propriétés sont introduites, il n'est pas logique d'avoir besoin d'ajouter de nouvelles méthodes de changement à chaque fois au lieu de cela, le nouveau change setstate(properties) imite plus étroitement l'existant setmarkbykey et setnodebykey pour obtenir l'ancien comportement, vous pouvez faire change setstate({ data }) le preservestatedata option de state tojson a changé le même comportement est maintenant appelé preservedata à la place cela le rend cohérent avec toutes les options existantes, et la nouvelle preservedecorations option également 0 25 — 21 septembre 2017 dernière minute le insertblock méthode de changement ne remplace plus les blocs vides auparavant, si vous utilisiez insertblock et que la sélection était dans un bloc vide, cela le remplaçait maintenant, vous devrez effectuer cette vérification vous même et utiliser la nouvelle replacenodebykey méthode à la place le block create et inline create méthodes ne normalisent plus auparavant, si vous en utilisiez un pour créer un bloc ou un élément en ligne avec zéro nœud, ils ajoutaient automatiquement un seul nœud de texte vide comme seul enfant cela était inattendu dans certaines situations, et si vous comptiez là dessus, vous devrez maintenant le gérer manuellement 0 24 — 11 septembre 2017 nouveau slate est maintenant un "monorepo" au lieu d'un seul package, slate a été divisé en packages individuels afin que vous puissiez uniquement exiger ce dont vous avez besoin, réduisant ainsi la taille des fichiers dans le processus, certains modules utiles qui étaient auparavant internes sont maintenant exposés il y a un nouveau slate hyperscript helper cela a été possible grâce au travail sur slate sugar https //github com/gitbookio/slate sugar , qui a ouvert la voie le slate prop types package est maintenant exposé auparavant, c'était un module interne, mais maintenant vous pouvez l'utiliser pour ajouter des types de propriétés à tous les composants ou plugins que vous créez le slate simulator package est maintenant exposé auparavant, c'était un utilitaire de test interne, mais maintenant vous pouvez l'utiliser dans vos propres tests également il est actuellement assez basique, mais nous pouvons y ajouter des fonctionnalités au fil du temps important immutable est maintenant un pair dépendance de slate auparavant, c'était une dépendance régulière, mais cela vous empêchait d'apporter votre propre version, sinon vous auriez eu des duplications vous devrez vous assurer de l'installer ! le html , plain et raw les sérialiseurs sont divisés en nouveaux paquets auparavant, vous les importiez depuis slate mais maintenant, vous les importerez depuis slate html serializer et slate plain serializer et le raw le sérialiseur qui a été déprécié est maintenant supprimé l' éditeur et placeholder les composants sont divisés en un nouveau paquet spécifique à react auparavant, vous les importiez depuis slate mais maintenant, vous importez { éditeur } de 'slate react' à la place 0 23 — 10 septembre 2017 nouveau les modèles slate ont maintenant model fromjson(object) et model tojson() méthodes ces méthodes fonctionnent avec la forme json canonique (qui était auparavant appelée "brut") de cette façon, vous n'avez pas besoin de importer un sérialiseur pour récupérer json, si vous avez le modèle, vous pouvez sérialiser/désérialiser les modèles ont également tojs et fromjs alias c'est juste pour correspondre aux objets immutable js, qui ont les deux méthodes pour slate cependant, les méthodes sont équivalentes breaking le isnative propriété de état a été supprimée auparavant, cela était utilisé pour des raisons de performance afin d'éviter le re rendu, mais ce n'est plus nécessaire cela ne devrait pas vraiment affecter la plupart des gens car il est rare que vous comptiez sur l'existence de cette propriété déprécié le brut sérialiseur est maintenant déprécié le concept entier de "brut" est en train d'être supprimé, au profit de permettre à tous les modèles de pouvoir sérialiser et désérialiser en json eux mêmes au lieu d'utiliser le brut sérialiseur, vous pouvez maintenant utiliser le fromjson et tojson directement sur les modèles les options toraw pour le simple et html sérialiseurs s'appellent maintenant tojson cela est pour rester symétrique avec la suppression du concept de "brut" partout le terse option pour la sérialisation json a été dépréciée ! cette option entraîne beaucoup de fuites d'abstraction car cela signifie qu'il n'y a pas de représentation json canonique des objets vous deviez travailler avec des données soit concises, soit non concises le html sérialiseur n'utilise plus la terse représentation cela ne devrait en fait poser problème à personne car la principale manifestation de cela a un avis de dépréciation avec un correctif en place pour l'instant le defaultblocktype du html sérialiseur s'appelle maintenant defaultblock cela vise simplement à rendre plus clair qu'il prend en charge non seulement la définition du type mais aussi données et isvoid 0 22 — 5 septembre 2017 nouveau l' state activemarks renvoie l'intersection des marques dans la sélection auparavant, il n'y avait que state marks qui renvoie les marques qui apparaissaient sur n'importe quel caractère dans la sélection mais state activemarks renvoie les marques qui apparaissent sur chaque caractère dans la sélection, ce qui est souvent plus utile pour mettre en œuvre les comportements standard des éditeurs de texte enrichi dernière minute l' sérialiseur simple ajoute maintenant des sauts de ligne entre les blocs auparavant, entre les blocs, le texte était joint sans aucun espace, mais ce n'était pas vraiment utile ou ce à quoi vous vous attendiez l' togglemark transforme maintenant vérifie l'intersection des marques auparavant, le basculement supprimait la marque de la plage si l'un des caractères d'une plage ne l'avait pas cependant, ce n'était pas ce que faisaient tous les autres éditeurs de texte enrichi, donc le comportement a changé pour imiter le comportement standard maintenant, si des caractères dans la sélection ont la marque appliquée, elle sera d'abord ajoutée lors du basculement le length propriété des nœuds a été supprimée cette propriété causait des problèmes avec du code comme dans lodash qui vérifiait la "similitude d'un tableau" en cherchant simplement une length propriété qui était un nombre onchange reçoit maintenant un change objet (précédemment nommé transform ) au lieu d'un state cela est nécessaire car cela impose que tous les changements soient représentés par un seul ensemble d'opérations sinon, en ce moment, il est possible de faire des choses comme state transform() apply({ save false }) transform() apply() et de perdre les informations d'opération dans l'historique avec ot, nous avons besoin que toutes les transformations qui peuvent se produire soient exposées et émises par l'éditeur la nouvelle syntaxe ressemble à onchange(change) { this setstate({ state change state }) } onchange({ state }) { this setstate({ state }) } de même, les gestionnaires reçoivent maintenant e, data, change au lieu de e, data, state au lieu de faire return state transform() apply() les plugins peuvent maintenant agir directement sur l'objet change les plugins peuvent toujours return change s'ils veulent interrompre la pile pour continuer vers d'autres plugins (tout != null valeur interrompra ) mais ils peuvent également ne rien retourner, et la pile appliquera leurs changements et continuera cela était auparavant impossible la nouvelle syntaxe ressemble à function onkeydown(e, data, change) { if (data key == 'enter') { return change splitblock() } } le onchange et on\[before]change les gestionnaires reçoivent maintenant change objets auparavant, ils recevaient également un état objet, mais maintenant ils reçoivent change objets comme le reste de l'api du plugin l' apply({ save }) option est maintenant state change({ save }) à la place c'est le moyen le plus simple de l'utiliser, mais cela nécessite que vous sachiez à l'avance s'il faut enregistrer ou non si vous souhaitez l'utiliser en ligne après avoir déjà enregistré des modifications, vous pouvez utiliser le change setoperationflag('save', true) drapeau à la place cela ne devrait pas être nécessaire pour 99 % des cas d'utilisation cependant le undo() et redo() transformations ne sauvegardent pas par défaut auparavant, vous deviez spécifiquement dire à ces transformations de ne pas sauvegarder dans l'historique, ce qui était gênant maintenant, elles ne sauvegarderont pas les opérations qu'elles annulent/réalisent par défaut onbeforechange n'est plus appelé depuis componentwillreceiveprops , lorsqu'un nouveau état est passé en tant que props au \<editor> composant cela a causé de nombreux problèmes de gestion d'état et était étrange au départ car passer des props entraînait des changements il est maintenant de la responsabilité du composant parent de ne pas passer des objets d'état mal formatés le splitnodebykey méthode de changement a été modifiée pour être superficielle auparavant, elle se divisait profondément jusqu'à un décalage mais maintenant, elle est superficielle et une autre splitdescendantsbykey méthode de changement a été ajoutée (avec une signature différente) pour le comportement de division profonde cela est nécessaire car les opérations de division et de jonction ont été modifiées pour être toutes superficielles, ce qui est requis afin que des transformations opérationnelles puissent être écrites contre elles les blocs ne peuvent plus avoir des enfants "inline" et "block" mélangés les blocs étaient implicitement censés contenir soit uniquement des nœuds "text" et "inline", soit uniquement des nœuds "block" les cas invalides sont maintenant normalisés par le schéma de base la forme de nombreuses opérations a changé cela était nécessaire pour rendre les opérations complètement inversibles sans aucun contexte supplémentaire les opérations n'ont jamais vraiment été exposées de manière consommable, donc je ne détaillerai pas tous les changements ici, mais n'hésitez pas à consulter la source pour voir les détails toutes les références aux nœuds "rejoindre" sont maintenant appelées "fusionner" cela est pour être légèrement plus clair, puisque la fusion ne peut se produire qu'avec des nœuds adjacents déjà, et pour avoir un meilleur parallèle avec "diviser", comme dans les cellules l'opération est maintenant appelée merge node , et les transformations sont maintenant merge déprécié la transform apply() méthode est dépréciée auparavant, c'est ici que l'enregistrement dans l'historique se produisait, mais cela a créé une convention maladroite qui n'était pas nécessaire maintenant, les opérations sont enregistrées dans l'historique au fur et à mesure qu'elles sont créées avec des méthodes de changement, au lieu d'attendre la fin vous pouvez accéder au nouveau état d'un changement à tout moment via change state 0 21 — 20 juillet 2017 important le html sérialiseur utilise maintenant domparser au lieu de cheerio auparavant, le html sérialiseur utilisait la cheerio bibliothèque pour représenter les éléments dans la logique de règle de sérialisation, mais cheerio était une dépendance très lourde elle a été supprimée, et le domparser natif du navigateur est maintenant utilisé à la place toutes les règles de sérialisation html devront être mises à jour si vous travaillez avec slate sur le serveur, vous pouvez maintenant passer un sérialiseur personnalisé au html constructeur, en utilisant la parse5 bibliothèque 0 20 — 17 mai 2017 important retourner null depuis le html le sérialiseur saute l'élément auparavant, null et indéfini avait le même comportement de saut de la règle et d'essai des autres règles maintenant, si vous retournez explicitement null cela sautera l'élément lui même 0 19 — 3 mars 2017 dernière minute le filterdescendants et finddescendants méthodes sont maintenant en profondeur d'abord cela ne devrait presque affecter personne, car ce ne sont généralement pas les meilleures choses à utiliser pour des raisons de performance si vous avez un cas d'utilisation très spécifique qui nécessite une recherche en largeur, (ou même probablement quelque chose de mieux), vous devrez l'implémenter vous même déprécié certaines méthodes node ont été dépréciées ! il y avait quelques méthodes qui avaient été ajoutées au fil du temps qui étaient soit mal nommées et qui ont été dépréciées et renommées, et une poignée de méthodes qui ne sont plus utiles pour la bibliothèque principale qui ont été dépréciées voici une liste complète aredescendantsorted > aredescendantssorted gethighestchild > getfurthestancestor obtenirleplushautparentenfantunique > obtenirl'ancêtreleplusloinenfantunique concaténerenfants décorertextes filtrerdescendantsprofond trouverdescendantprofond obtenirenfantsentre obtenirenfantsentreinclus estinlinediviséàplage 0 18 — 2 mars 2017 dernière minute le plugin render propriété s'appelle maintenant plugin renderportal cela permet de faire place à la nouvelle plugin render propriété qui offre un comportement similaire à hoc, afin que les plugins puissent augmenter l'éditeur comme ils le souhaitent 0 17 — 27 février 2017 obsolete certaines sélection méthodes ont été déclarées obsolètes ! auparavant, il y avait de nombreuses incohérences dans la nomination et la gestion des changements de sélection tout cela a été nettoyé, mais dans le processus, certaines méthodes ont été déclarées obsolètes voici une liste complète des méthodes obsolètes et de leurs nouvelles alternatives movetooffsets > moveoffsetsto moveforward > move reculer > déplacer déplaceroffsetancre > déplacerancre déplaceroffsetfocus > déplacerfocus déplaceroffsetdébut > déplacerdébut déplaceroffsetfin > déplacerfin étendreversavant > étendre étendreversarrière > étendre annuler > désélectionner certaines transformations de sélection ont été dépréciées ! avec les méthodes, les transformations basées sur la sélection ont également été refactorisées, entraînant des dépréciations voici une liste complète des transformations dépréciées et de leurs nouvelles alternatives moveto > select movetooffsets > moveoffsetsto moveforward > move movebackward > move movestartoffset > movestart moveendoffset > moveend extendforward > extend étendreversarrière > étendre inversersélection > inverser annulersélection > désélectionner annulermarques 0 16 — 2 décembre 2016 dernière minute les nœuds en ligne sont maintenant toujours entourés de nœuds de texte auparavant, ce comportement ne se produisait que pour les nœuds en ligne avec isvoid true maintenant, tous les nœuds en ligne seront toujours entourés de nœuds de texte si les nœuds de texte n'existent pas, des vides seront créés cela permet un comportement plus cohérent à travers slate, et une parité avec d'autres expériences d'édition 0 15 — 17 novembre 2016 dernière nouvelle la clé unique clé générée a changé auparavant, slate générait des clés uniques qui ressemblaient à '9dk3' mais elles n'étaient pas très résistantes aux conflits maintenant, les clés sont de simples chaînes de nombres auto incrémentés, comme '0' , '1' , '2' cela rend plus clair que les clés sont simplement un moyen pratique de référencer de manière unique des nœuds dans le court terme durée de vie d'une seule instance en mémoire de slate elles ne sont pas conçues pour être utilisées pour une unicité à long terme une nouvelle setkeygenerator fonction a été exportée qui vous permet de passer votre propre mécanisme de génération de clés si vous souhaitez garantir l'unicité le raw sérialiseur ne préserve pas les clés par défaut auparavant, le raw sérialiseur omettait les clés lorsqu'il était passé l'option terse true mais les préservait sans elle maintenant, il omettra toujours les clés, à moins que vous ne passiez la nouvelle option preservekeys true cela reflète mieux que les clés sont des id temporaires en mémoire les opérations sur le document mettent maintenant à jour la sélection lorsque cela est nécessaire cela ne vous affectera pas à moins que vous ne fassiez des choses très spécifiques avec des transformations et la mise à jour des sélections dans l'ensemble, cela rend beaucoup plus facile d'écrire des transformations, car dans la plupart des cas, les opérations sous jacentes mettront à jour la sélection comme vous vous y attendez sans que vous ayez à faire quoi que ce soit déprécié les méthodes d'accès aux nœuds n'acceptent plus de recevoir un autre nœud ! auparavant, les méthodes d'accès aux nœuds comme node getparent pouvaient recevoir soit une clé sous forme de chaîne ou un objet nœud pour des raisons de performance, le passage d'un objet nœud est en cours de dépréciation donc, si vous avez des appels qui ressemblent à node getparent(descendant) , ils devront maintenant être écrits comme node getparent(descendant key) ils lanceront un avertissement pour l'instant, et lanceront une erreur dans une version ultérieure de slate 0 14 — 10 septembre 2016 brisant le annuler et répéter les transformations doivent être appliquées ! auparavant, annuler et répéter étaient des cas spéciaux de sorte qu'ils ne nécessitaient pas un apply() appel, et au lieu de cela, ils renvoyaient un nouveau état directement maintenant, ce n'est plus le cas, et ils sont comme toutes les autres transformations les transformations ne sont plus exposées sur état ou nœud l'api des transformations a été complètement refactorisée pour être construite à partir d'"opérations" pour le support de l'édition collaborative dans le cadre de ce refactor, les transformations ne sont désormais disponibles que via le state transform() api, et ne sont pas exposées sur les état ou nœud objets comme c'était le cas auparavant l'objet de transformation est maintenant mutable auparavant l'objet de transformation était un immutable js enregistrement , mais maintenant c'est un simple constructeur cela est dû au fait que les transformations modifient intrinsèquement leur représentation d'un état, mais cette décision est https //github com/ianstormtaylor/slate/issues/328 la sélection peut maintenant être "non définie" auparavant, une sélection ne pouvait jamais être dans un état "non défini" où le anchorkey ou focuskey était nul cela n'est plus techniquement vrai, bien que cela ne devrait vraiment affecter personne en pratique 0 13 — 15 août 2016 dernière minute le rendernode et rendermark propriétés ont disparu! auparavant, le rendu des nœuds et des marques se faisait via ces deux propriétés de l' \<editor> , mais cela a été remplacé par la nouvelle schema propriété consultez les exemples mis à jour pour voir comment définir un schéma! il y a de bonnes chances que cela élimine du code supplémentaire pour la plupart des cas d'utilisation! 😄 la renderdecorations propriété a disparu! le rendu des décorations a également été remplacé par la nouvelle schema propriété de l' \<editor> 0 12 — 9 août 2016 dernière minute le data files propriété est maintenant un tableau auparavant, c'était un filelist objet, mais il a dû être changé pour ajouter un support complet pour le collage et le glissement de fichiers dans tous les navigateurs cela ne devrait pas vous affecter à moins que vous ne comptiez spécifiquement sur le fait qu'il soit semblable à un tableau au lieu d'un vrai tableau 0 11 — 4 août 2016 dernière minute les nœuds vides sont à nouveau rendus implicitement ! auparavant, slate exigeait que vous enveloppiez vous même les rendus de nœuds vides avec le composant d'enveloppement exposé \<void> cela était pour permettre le style de sélection, mais un changement a été effectué pour permettre au style de sélection d'être géré en javascript maintenant, le \<void> enveloppant sera rendu implicitement par slate, donc vous n'avez pas besoin de vous en soucier, et la "vidéité" n'a besoin d'être basculée qu'à un seul endroit, le isvoid true propriété d'un nœud 0 10 — 29 juillet 2016 dernière minute les marques sont maintenant rendables en tant que composants auparavant, la seule façon prise en charge pour rendre les marques était de retourner un style objet maintenant, vous pouvez retourner un objet de style, une chaîne de nom de classe, ou un composant react complet en raison de cela, le dom sera rendu légèrement différemment qu'auparavant, ce qui entraînera un extra \<span> lors du rendu des marques non composants cela ne vous affectera pas à moins que vous ne dépendiez de la sortie dom de slate pour une raison quelconque 0 9 — 28 juillet 2016 dernière minute le wrap et unwrap les signatures de méthode ont changé ! auparavant, vous passiez type et data comme paramètres séparés, par exemple wrapblock('code', { src true }) cela était incohérent avec d'autres transformations, et a été mis à jour de sorte qu'un seul argument de propriétés soit passé à la place donc cet exemple pourrait maintenant être wrapblock({ type 'code', { data { src true }}) vous pouvez toujours passer une type chaîne comme abréviation, ce qui sera le cas d'utilisation le plus fréquent, par exemple wrapblock('code') 0 8 — 27 juillet 2016 dernière minute le onkeydown et onbeforeinput les signatures des gestionnaires ont changé ! auparavant, certains gestionnaires slate avaient une signature de (e, state, editor) et d'autres avaient une signature de (e, data, state, editor) maintenant, tous les gestionnaires recevront un data objet—qui contient des données spécifiques à slate liées à l'événement—même s'il est vide cela est utile pour la compatibilité future où nous pourrions avoir besoin d'ajouter des données à un gestionnaire qui n'en avait auparavant pas, et c'est plus agréable pour la cohérence le onkeydown la nouvelle data objet du gestionnaire contient le nom de la clé, code et une série de is propriétés pour faciliter le travail avec les touches de raccourci le onbeforeinput la nouvelle data objet est vide le utils export a été supprimé auparavant, un key utilitaire et le finddomnode utilitaire étaient exposés sous l'objet utils le key a été supprimé au profit de l'objet data passé à onkeydown et ensuite finddomnode utilitaire a été mis à niveau en tant qu'export nommé de niveau supérieur, donc vous devrez maintenant y accéder via import { finddomnode } from 'slate' les nœuds vides ont maintenant de manière permanente " " comme contenu auparavant, ils contenaient une chaîne vide, mais ce n'est pas techniquement correct, car ils ont du contenu et ne devraient pas être considérés comme "vides" maintenant, ils auront un seul espace de contenu cela ne devrait vraiment affecter personne, à moins que vous n'ayez eu accès à cette chaîne pour la sérialisation les nœuds en ligne vides sont maintenant impossibles cela est pour rester cohérent avec le contenteditable comportement natif, où bien que techniquement les éléments puissent exister, ils ont un comportement étrange et ne peuvent jamais être sélectionnés 0 7 — 24 juillet 2016 en direct le raw sérialiseur n'est plus concis par défaut ! auparavant, le raw sérialiseur renvoyait une représentation "concise" du document, omettant les informations qui n'étaient pas strictement nécessaires pour désérialiser plus tard, comme la clé des nœuds par défaut, cela ne se produit plus vous devez opter pour ce comportement en passant { terse true } comme le deuxième argument des méthodes désérialiser et sérialiser unhandled content type 0 6 — 22 juillet 2016 dernière minute les composants vides ne sont plus rendus implicitement ! auparavant, slate enveloppait automatiquement tout nœud avec isvoid true dans un \<void> composant mais cela empêchait de personnaliser l'enveloppe, comme d'ajouter un classname ou style propriété vous devez maintenant rendre l'enveloppe vous même , et elle a été exportée comme slate void cela, combiné à un petit changement dans la structure du composant \<void> permet à l'état "sélectionné" des nœuds vides d'être rendu uniquement avec css basé sur la \ focus propriété d'un \<void> élément, qui auparavant https //github com/ianstormtaylor/slate/commit/31782cb11a272466b6b9f1e4d6cc0c698504d97f cela nous permet de rationaliser la logique de gestion de la sélection, améliorant les performances et réduisant la complexité data offset key est maintenant \<key> \<index> au lieu de \<key> \<start> \<end> cela ne devrait en fait affecter personne, à moins que vous ne comptiez spécifiquement sur cet attribut dans le dom ce changement réduit considérablement le nombre de re rendus nécessaires, car auparavant, tout caractère supplémentaire entraînait un changement en cascade dans le \<start> et \<end> décalages des plages de texte suivantes 0 5 — 20 juillet 2016 dernière minute node gettextnodes() est maintenant node gettexts() c'est juste pour la cohérence avec les autres méthodes existantes de node comme getblocks() , getinlines() , etc et c'est agréablement plus court 😉 node les méthodes maintenant lancent plus tôt lors d'états inattendus cela ne devrait rien casser pour la plupart des gens, à moins qu'un cas particulier étrange ne soit passé inaperçu auparavant 0 4 — 20 juillet 2016 dernière minute rendermark(mark, state, editor) est maintenant rendermark(mark, marks, state, editor) ce changement vous permet de rendre des marques basées sur plusieurs marques présentes en même temps sur une plage de texte donnée, par exemple en utilisant une police personnalisée bolditalic otf lorsque le texte a à la fois gras et italique marques 0 3 — 20 juillet 2016 dernière minute transform unwrapblock() déballage sélectif auparavant, appeler unwrapblock avec une plage représentant un frère du milieu déballerait tous les frères, supprimant complètement le bloc d'emballage maintenant, l'appeler avec ces mêmes arguments déplacera uniquement le frère du milieu d'un niveau dans la hiérarchie, préservant l'imbrication de ses frères ce changement rend beaucoup plus simple l'implémentation de fonctionnalités comme le déballage d'un seul élément de liste, qui auparavant déballerait toute la liste 0 2 — 18 juillet 2016 dernière minute transform mark() est maintenant transform addmark() et transform unmark() est maintenant transform removemark() les nouveaux noms rendent plus clair que les transformations sont des actions effectuées, et cela ouvre la voie à l'ajout d'un togglemark commodité également 0 1 — 13 juillet 2016 🎉