Registro de cambios

esta es una lista de cambios en slate con cada nueva versión hasta que 1 0 sea lanzada, los cambios importantes se agregarán como aumentos de versión menor, y los cambios más pequeños a nivel de parches no se notarán ya que la biblioteca se está moviendo rápidamente mientras está en beta ⚠️ hasta que https //github com/atlassian/changesets/issues/264 se resuelva, cada paquete mantendrá su propio changelog individual, que puedes encontrar aquí 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 de marzo de 2021 cambio importante nuevos customtypes para editor, elemento, texto y otros objetos específicos de implementación la mejora de la tipificación con typescript te permite agregar customtypes para el editor de slate este cambio requiere que configures tus tipos al inicio es un nuevo concepto, así que por favor lee la nueva documentación de typescript aquí https //docs slatejs org/concepts/11 typescript 0 60 — 24 de noviembre de 2020 última hora se introdujeron nuevos tipos de typescript personalizables puedes anular los tipos incorporados para extenderlos para el modelo de dominio de tu propio editor sin embargo, los cambios para hacer esto posible probablemente resultaron en algunos cambios en los contratos de tipo existentes el useeditor hook fue renombrado a useslatestatic esto se hizo para diferenciar mejor entre el useslate hook y para dejar claro que la versión estática no se volverá a renderizar cuando ocurran cambios 0 59 — 24 de septiembre de 2020 no hubo cambios importantes ni nuevas adiciones en esta versión 0 58 — 5 de mayo de 2020 importante las propiedades de usuario en elementos y textos ahora tienen un tipo desconocido en lugar de cualquier otro anteriormente, las claves definidas por el usuario de forma arbitraria en el texto y elemento tenían un tipo de cualquiera lo que efectivamente eliminó cualquier posible verificación de tipo en esas propiedades ahora tienen un tipo de desconocido para que la verificación de tipo pueda ser realizada por los consumidores de la api cuando apliquen sus propias propiedades personalizadas a los textos y elementos 0 57 — 18 de diciembre de 2019 importante los comandos sobreescribibles ahora viven directamente en el objeto del editor anteriormente, el concepto de comando se implementaba como una interfaz que se pasaba a la función editor exec , permitiendo que los comandos "núcleo" fueran sobreescritos en un solo lugar pero esto introdujo mucha indirecta similar a redux al implementar comandos personalizados que no era necesaria porque nunca se sobreescriben en su lugar, ahora las acciones centrales que pueden ser sobreescritas se implementan como funciones individuales en el editor (por ejemplo, editor inserttext ) y pueden ser sobreescritas como cualquier otra función (por ejemplo, isvoid ) anteriormente, para anular un comando harías const withplugin = editor => { const { exec } = editor editor exec = command => { if (command type === 'insert text') { const { text } = command if (mycustomlogic) { // return } } exec(command) } return editor } ahora, anularías la función específica directamente const withplugin = editor => { const { inserttext } = editor editor inserttext = text => { if (mycustomlogic) { // return } inserttext(text) } return editor } ¡nunca deberías necesitar llamar a estas funciones directamente! están ahí para que los plugins las utilicen, pero hay ayudantes de nivel superior que puedes llamar cada vez que realmente necesites invocarlas sigue leyendo… las transformaciones ahora viven en un espacio de nombres separado de ayudantes anteriormente, los ayudantes de transformación de documento y selección estaban disponibles directamente en el editor interfaz como editor pero estos ayudantes son bastante de bajo nivel, y no son algo que usarías en tu propio código en todas partes, generalmente solo dentro de ayudantes personalizados específicos de tu propia creación para hacer espacio para comandos personalizados de usuario, estos ayudantes se han trasladado a un nuevo transformaciones espacio de nombres anteriormente escribirías editor unwrapnodes(editor, ) ahora escribirías transforms unwrapnodes(editor, ) el comando interfaces fueron eliminadas como parte de esos cambios, el existente comando , corecommand , historycommand , y reactcommand interfaces fueron todas eliminadas ya no necesitas definir estos "objetos de comando", porque puedes llamar a las funciones directamente los plugins aún pueden definir sus propios comandos sobreescribibles extendiendo el editor interface con nuevas funciones el slate react plugin hace esto con insertdata y el slate history plugin hace esto con deshacer y rehacer nuevo los ayudantes de acción del usuario ahora viven directamente en el editor interface estos están ocupando el lugar de los existentes transforms ayudantes que fueron movidos estos ayudantes son equivalentes a acciones de usuario, y siempre operan sobre la selección existente hay algunos definidos por el núcleo, pero es probable que definas tus propios ayudantes personalizados que sean específicos para tu dominio también por ejemplo, aquí hay algunas de las acciones integradas editor inserttext(editor, 'a string of text') editor deleteforward(editor) editor deletebackward(editor, { unit 'word' }) editor addmark(editor, 'bold', true) editor insertbreak(editor) cada uno de los antiguos "comandos del núcleo" tiene un equivalente editor ayudante expuesto ahora sin embargo, puedes definir fácilmente tus propios ayudantes personalizados y colocarlos en un espacio de nombres también const myeditor = { editor, insertparagraph(editor) { }, toggleboldmark(editor) { }, formatlink(editor, url) { }, } ¡lo que tenga sentido para su caso de uso específico! 0 56 — 17 de diciembre de 2019 última hora el format text comando se divide en add mark y remove mark aunque el objetivo es mantener el número de comandos en el núcleo al mínimo, tener esto como un comando combinado hacía muy difícil escribir lógica que quisiera garantizar que solo se agregara o eliminara una marca de un nodo de texto ahora se puede garantizar que el add mark comando solo agregará propiedades personalizadas a los nodos de texto, y el remove mark comando solo los eliminará anteriormente escribirías editor exec({ type 'format text', properties { bold true }, }) ahora escribirías if (isactive) { editor exec({ type 'remove mark', key 'bold' }) } else { editor exec({ type 'add mark', key 'bold', value true }) } 🤖 tenga en cuenta que el término "marca" no significa lo que significaba en 0 47 y versiones anteriores simplemente significa formato que se aplica a nivel de texto—negrita, cursiva, etc necesitamos un término para ello porque es un patrón tan común en editores de texto enriquecido, y "marca" es a menudo el término que se utiliza por ejemplo, la \<mark> etiqueta en html el node text ayudante fue renombrado a node string esto fue simplemente para reducir la confusión entre "la cadena de texto" y "nodos de texto" el ayudante aún solo devuelve el contenido de cadena concatenado de un nodo 0 55 — 15 de diciembre de 2019 ruptura la opción de coincidencia ahora debe ser una función anteriormente había algunos atajos, como pasar un objeto simple este comportamiento fue eliminado porque dificultaba razonar exactamente sobre lo que se estaba coincidiendo, dificultaba la depuración y dificultaba escribir bien ahora la opción de coincidencia debe ser una función que recibe el node objeto para coincidir si estás usando typescript, y la función que pasas es un guardia de tipo, ¡eso se tendrá en cuenta en el valor de retorno! anteriormente podrías escribir editor nodes(editor, { at range, match 'text', }) editor nodes(editor, { at range, match { type 'paragraph' }, }) ahora escribirías editor nodes(editor, { at range, match text istext, }) editor nodes(editor, { at range, match node => node type === 'paragraph', }) la opción modo ahora por defecto es 'más bajo' anteriormente, el valor por defecto variaba dependiendo de dónde se usaba en la base de código ahora por defecto es 'más bajo' en todas partes, y siempre puedes pasar 'más alto' para cambiar el comportamiento la única excepción es el editor nodes ayudante que por defecto es 'todos' ya que ese es el comportamiento esperado la mayor parte del tiempo el editor match ayudante fue renombrado a editor above esto fue solo para dejar claro cómo buscaba en el árbol—mira a través de todos los nodos directamente arriba de una ubicación en el documento los editor above/previous/next ayudantes ahora toman todas las opciones en un diccionario anteriormente, sus apis no coincidían exactamente con el editor nodes ayudante para el cual son abreviaturas, pero ahora esto ya no es el caso el at , match y modo opciones se pasan todas en el argumento anteriormente usarías editor previous(editor, path, n => text istext(n), { mode 'lowest', }) ahora usarías editor previous(editor, { at path, match n => text istext(n), mode 'lowest', }) el editor elements y editor texts ayudantes fueron eliminados estos eran ayudantes de conveniencia simples que rara vez se usaban ahora puedes lograr lo mismo utilizando el editor nodes ayudante directamente junto con el match opción por ejemplo editor nodes(editor, { at range, match element iselement, }) 0 54 — 12 de diciembre de 2019 noticias de última hora el \<slate> onchange ya no recibe el argumento de selección anteriormente recibía (valor, selección) , ahora simplemente recibe (valor) en su lugar, puedes acceder a cualquier propiedad del editor directamente (incluyendo el valor como editor children ) la convención de valor/onchange se proporciona únicamente para casos de uso relacionados con formularios que lo esperan esto es junto con el cambio en cómo se "controlan" las propiedades adicionales por defecto son no controladas, pero puedes pasar cualquiera de las otras propiedades de nivel superior del editor para tomar control de ellas el comando y corecommand se han separado anteriormente podías acceder a command iscorecommand , sin embargo ahora este ayudante vive directamente en la interfaz de comando central como corecommand iscorecommand esto lo hace más simétrico con los comandos de usuario los verificadores de comandos se han simplificado anteriormente slate exponía ayudantes de verificación de comandos como command isinserttextcommand sin embargo, estos eran verbosos y no útiles la mayor parte del tiempo en su lugar, ahora puedes verificar corecommand iscorecommand y luego usar la propiedad command type para afinar más esto mantiene el núcleo más simétrico con cómo los usuarios implementarán comandos personalizados nuevo el \<slate> componente ahora es pseudo controlado requiere un value= prop que debe ser pasado y que está controlado sin embargo, la selección , marcas , historia , o cualquier otra prop no requiere ser controlada por defecto, son no controladas si tu caso de uso requiere controlar estas props adicionales, puedes pasarlas y comenzarán a ser controladas nuevamente este cambio se realizó para facilitar el uso de slate, mientras se permite que un estado más complejo sea controlado por el núcleo o plugins en el futuro—un estado del que los usuarios no necesitan preocuparse la mayor parte del tiempo el editor ahora tiene una propiedad de marcas esta propiedad representa el formato a nivel de texto que se aplicará al siguiente carácter que se inserte este es un comportamiento común de los editores de richtext, donde presionar un botón de negrita con una selección colapsada activa el modo de formato "negrita", y luego escribir un carácter se vuelve en negrita este estado no se almacena en el documento, y en su lugar se almacena como una propiedad adicional en el propio editor 0 53 — 10 de diciembre de 2019 noticia de última hora el paquete slate schema ha sido eliminado! esta decisión se tomó porque con los nuevos ayudantes en el editor interfaz, y con los cambios en normalizenode en la última versión de slate, agregar restricciones usando normalizenode en realidad conduce a un código más mantenible que usar slate schema anteriormente era necesario para evitar que las cosas se volvieran demasiado ilegibles, pero eso siempre tenía un gran costo de indirecta y aprendizaje de apis adicionales todo lo que podías hacer con slate schema puedes hacerlo con normalizenode , y más las funciones de coincidencia de nodos ahora reciben solo un nodo anteriormente recibían un nodeentry tupla, que consistía en \[nodo, ruta] sin embargo, ahora reciben solo un nodo argumento, lo que facilita escribir ayudantes de verificación de nodos únicos y pasarlos directamente como argumentos si necesitas asegurar una ruta, busca primero el nodo se eliminaron algunos ayudantes innecesarios había un puñado de ayudantes sobrantes que no se usaban en ninguna parte de la lógica central de slate, y era muy poco probable que se usaran en el espacio del usuario, por lo que se han eliminado para reducir el tamaño del paquete siempre eres libre de reimplementarlos si realmente los necesitas la lista de ayudantes eliminados es editor ancestor node cercano node más lejano rango existe rango eslistaderangos rango esmapaderangos 0 52 — 5 de diciembre de 2019 última hora el slate schema paquete ahora exporta una fábrica anteriormente importabas el conesquema función directamente del paquete, y pasabas tus reglas de esquema cuando lo llamabas sin embargo, ahora importas la definiresquema fábrica en su lugar, que toma tus reglas de esquema y devuelve una función de plugin personalizada conesquema de esta manera, aún puedes usar ayudantes como componer con el plugin, mientras predefines tus reglas personalizadas el validación de propiedades en el esquema ahora es exhaustiva anteriormente, una validación de propiedades verificaría cualquier propiedad que definieras y dejaría las desconocidas tal como están esto dificultaba estar seguro de qué propiedades terminarían en un nodo ahora, cualquier propiedad no definida se considera inválida y usar un {} de validación vacía aseguraría que no haya propiedades personalizadas en absoluto nuevo la validación del esquema asegura el formato a nivel de texto puedes usarlo desde cualquier nodo de elemento superior en el árbol, para garantizar que solo contenga ciertos tipos de formato a nivel de texto en sus nodos de texto internos por ejemplo, podrías usarlo para asegurarte de que un bloque de código no permita que ninguno de su texto esté en negrita o en cursiva 0 51 — 5 de diciembre de 2019 ruptura ¡la interfaz mark ha sido eliminada! anteriormente, el formato a nivel de texto se almacenaba en un arreglo de marcas únicas ahora, ese mismo formato se almacena directamente en los nodos de texto mismos por ejemplo, en lugar de { text 'a line of text ', marks \[{ type 'bold' }], } ahora tienes { text 'a line of text ', bold true, } y las marcas se añaden y se eliminan de los nodos de texto utilizando el mismo editor setnodes transformación que usas para alternar el formato en nodos de bloque e inline esto simplifica mucho las cosas y hace que el núcleo de slate sea aún más pequeño el \<slate> componente ahora es un componente "controlado" esto hace que las cosas sean un poco más al estilo de react, y facilita la actualización del valor del editor cuando se reciben nuevos datos después de la renderización inicial para llegar al comportamiento anterior "no controlado" necesitarás implementarlo en el espacio del usuario utilizando los hooks integrados de react mientras que anteriormente harías \<slate defaultvalue={initialvalue}> \</slate> ahora debes gestionar el valor y la selección tú mismo, como 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 de noviembre de 2019 última hora una revisión completa la base de código de slate ha tenido una revisión completa y muchas piezas de su arquitectura central han sido reconsideradas desde cero hay muchos cambios recomendamos volver a leer la https //docs slatejs org/walkthroughs y https //docs slatejs org/concepts documentación y los https //github com/ianstormtaylor/slate/tree/71ff94c8d866a3ad9582ec4b84258d99d508fd70/site/examples/readme md para tener una idea de todo lo que ha cambiado así como el https //docs slatejs org/concepts/xx migrating sobre cuáles son los cambios principales ⚠ advertencia los cambios a partir de este punto se refieren a la arquitectura anterior de slate, basada en immutable js y sin typescript muchas cosas son diferentes en la arquitectura anterior y pueden no aplicarse a la nueva 0 47 — 8 de mayo de 2019 nuevo presentando el modelo de anotación esto es muy similar a lo que solía almacenarse en value decorations , excepto que también contienen una "clave" única para ser identificados pueden ser utilizados para cosas como comentarios, sugerencias, cursores colaborativos, etc { object 'annotation', key string, type string, data map, anchor point, focus point, } hay tres nuevas anotación operaciones el conjunto de operaciones ahora incluye add annotation , remove annotation y set annotation son similares a las existentes marcar operaciones presentando métodos del modelo "iterable" esto introduce varios métodos que producen iterables en la interfaz element , que document , block y inline implementan todos hay iterables para recorrer todo el árbol element blocks(options) element descendants(options) element inlines(options) element texts(options) element ancestors(path, options) element siblings(path, options) puedes usarlos igual que los iterables nativos de javascript por ejemplo, puedes recorrer los nodos de texto después de un nodo específico for (const next of document texts({ path start path })) { const \[node, path] = next // do something with the text node or its path } o puedes recorrer todos los bloques "hoja" for (const \[block] of document blocks({ onlyleaves true })) { // } y debido a que estas iteraciones utilizan bucles nativos for/of , puedes fácilmente interrumpir o devolver directamente de los bucles—una experiencia de desarrollo mucho más agradable que recordar devolver falso rompiendo el value decorations propiedad ahora es value annotations siguiendo con la división de decoraciones en anotaciones, esta propiedad también fue renombrada ahora deben contener claves únicas key propiedades, ya que se almacenan como un map en lugar de una list esto permite actualizaciones mucho más eficientes el decoration modelo ya no tiene un mark propiedad anidada anteriormente, un verdadero mark objeto se utilizaba como propiedad en decoraciones, pero ahora las type y data propiedades son propiedades de primera clase en su lugar { object 'decoration', type string, data map, anchor point, focus point, } 0 46 — 1 de mayo de 2019 última hora las operaciones de marca ya no tienen desplazamiento o longitud propiedades dado que los nodos de texto ahora contienen un conjunto único de marcas, no tendría sentido que una sola operación relacionada con marcas resultara en una división de nodos en cambio, cuando se agrega una marca solo a parte de un nodo de texto, resultará en una split node operación así como en una add mark operación las operaciones de texto ya no tienen una marcas propiedad anteriormente se utilizaba para agregar texto con un conjunto específico de marcas sin embargo, esto ya no es necesario, y cuando se agrega texto con marcas resultará en una insert text operación así como en una add mark operación usando text create o text createlist con un hojas propiedad dará error ahora que los nodos de texto ya no tienen hojas, necesitarás pasar la cadena de texto y marcas directamente al crear un nuevo nodo de texto (sin embargo, aún puedes crear valores completos usando value create de una manera compatible hacia atrás por conveniencia mientras migras ) // this works, although deprecated, which is the common case value create(oldvaluejson) // but this will error! text create(oldtextjson) value tojson devuelve el nuevo formato del modelo de datos, sin hojas aunque value fromjson y value create permiten el formato antiguo en modo obsoleto, llamando a value tojson devolverá el nuevo formato de datos si aún necesitas el antiguo, tendrás que iterar el árbol del documento convirtiendo los nodos de texto tú mismo los métodos de mutación de bajo nivel value y node han cambiado estos cambios siguen los cambios en la firma de operación, ya que los métodos toman los mismos argumentos que las operaciones en sí por ejemplo // previously value addmark(path, offset, length, mark) // is now value addmark(path, mark) estos son métodos de bajo nivel, por lo que este cambio no debería afectar la mayoría de los casos de uso obsoleto inicializando editores con text nodos con una propiedad de hojas está obsoleto en esta nueva versión de slate, crear un nuevo valor con value create con el antiguo modelo de datos de hojas aún está permitido por conveniencia en la migración, pero se eliminará en una próxima versión (sin embargo, usar el bajo nivel text create ¡dará un error!) // this works, although deprecated, which is the common case value create(oldvaluejson) // but this will error! text create(oldtextjson) 0 45 — 2 de abril de 2019 última hora algunas propiedades de operación han cambiado en un esfuerzo por estandarizar y simplificar las operaciones, sus propiedades han cambiado esto no afectará el 90% de los casos de uso, ya que las operaciones suelen ser preocupaciones de bajo nivel sin embargo, si estás utilizando transformaciones operativas o algunas otras partes de bajo nivel de slate, esto puede afectarte el valor , selección , nodo , y marca propiedades—que contenían referencias a objetos de immutable js—han sido eliminadas en su lugar, hemos estandarizado un propiedades y nuevaspropiedades par esto reducirá enormemente el tamaño de las operaciones almacenadas en memoria, y facilitará su manejo cuando se serialicen también 0 44 — 8 de noviembre de 2018 nuevo presentando el child min invalid y child max invalid errores de esquema estos nuevos errores de esquema se mapean directamente a los mix y max definiciones de reglas de esquema, y facilitan determinar exactamente qué necesita hacer su lógica de normalización para corregir el documento se añadieron nuevos métodos de recuperación de nodos hay tres nuevos métodos para la recuperación de nodos el primero es getnodesatrange que recuperará todos los nodos en el árbol en un rango dado y los otros dos son getrootblocksatrange y getrootinlinesatrange para recuperar los bloques o inlines más altos en un rango dado estos deberían ser útiles para definir su propia lógica de comandos ruptura errores de esquema para min y max las reglas han cambiado anteriormente, resultarían en errores de child required , child object invalid , child type invalid y child unknown ahora que tenemos los nuevos child min invalid y child max invalid errores, estas reglas de esquema los devolverán en su lugar, facilitando mucho determinar exactamente qué regla está causando un error de esquema desaprobado el getblocksatrange y getinlinesatrange métodos han sido renombrados para aclarar la confusión sobre qué bloques e inlines se recuperan en el caso de anidamiento, estos dos métodos han sido renombrados a getleafblocksatrange y getleafinlinesatrange para aclarar que recuperan los nodos más bajos y ahora hay dos métodos adicionales llamados getrootblocksatrange y getrootinlinesatrange para casos en los que deseas los nodos más altos en su lugar 0 43 — 27 de octubre de 2018 nuevo el editor command y editor query métodos pueden tomar funciones anteriormente solo aceptaban una cadena de tipo y buscaban el comando o consulta por tipo ahora, también aceptan una función personalizada esto es útil para los autores de plugins, que quieren aceptar una "opción de comando", ya que les da a los usuarios más flexibilidad para escribir comandos o consultas únicas por ejemplo, un plugin podría recibir ya sea hotkey({ hotkey 'cmd+b', command 'addboldmark', }) o una función de comando personalizada hotkey({ hotkey 'cmd+b', command editor => editor addboldmark() movetoend(), }) última hora el cambio objeto ha sido eliminado el cambio objeto tal como lo conocíamos anteriormente ha sido eliminado, y todos sus comportamientos han sido incorporados en el editor controlador esto incluye los comandos y métodos de consulta de nivel superior, así como métodos como applyoperation y normalize todos los lugares que solían recibir cambio ahora reciben editor , que es equivalente a la api los cambios ahora se envían a onchange de forma asíncrona anteriormente, esto se hacía de forma sincrónica, lo que resultaba en algunas extrañas condiciones de carrera en entornos de react ahora siempre se enviarán de forma asíncrona, al igual que setstate el normalize y validate las firmas de middleware han cambiado! anteriormente, el normalize y validate middleware se pasaba (nodo, siguiente) sin embargo, ahora, para ser consistentes con el otro middleware, todos se pasan (nodo, editor, siguiente) de esta manera, todo el middleware siempre recibe editor y siguiente como sus dos últimos argumentos el editor event método ha sido eliminado anteriormente, esto es lo que usarías al escribir pruebas para simular eventos que se disparaban, que eran ligeramente diferentes a otros middleware en ejecución con la simplificación del editor y las nuevas firmas de middleware consistentes, ahora puedes usar editor run directamente para simular eventos editor run('onkeydown', { key 'tab', }) deprecated el editor change método está en desuso con la eliminación del change objeto, ya no es necesario crear los pequeños cierres con editor change() en su lugar, puedes invocar directamente comandos en el editor en serie, y todos los cambios se emitirán de forma asíncrona en el siguiente tick editor inserttext('word') movefocusforward(10) addmark('bold') el applyoperations método está en desuso en su lugar, puedes iterar un conjunto de operaciones y aplicar cada una usando applyoperation esto es para reducir el número de métodos expuestos en el editor para mantenerlo más simple el change call método está en desuso anteriormente, esto se usaba para llamar a una función única como un método de cambio ahora este comportamiento es equivalente a llamar a editor command(fn) en su lugar 0 42 — 9 de octubre de 2018 nuevo presentando el editor controlador anteriormente había un concepto vago de editor que era el componente react en sí esto era útil, pero debido a que estaba estrechamente acoplado a react y al navegador, no se prestaba bien a casos de uso fuera del navegador esto significaba que la línea entre "modelo" y "controlador/vista" estaba difusa, y algunos conceptos existían en ambos lugares a la vez, de maneras inconsistentes un nuevo editor controlador ahora hace clara esta relación toma prestados muchos de sus comportamientos del componente react \<editor> y el componente en realidad solo instancia su propio editor de javascript simple para delegar el trabajo este nuevo concepto impulsa gran parte del pensamiento en esta nueva versión, desbloqueando muchos cambios que traen una separación más clara de responsabilidades a slate nos permite crear editores en cualquier entorno, lo que facilita los casos de uso del lado del servidor, trae paridad a las pruebas e incluso nos abre a soportar otras capas de vista como react native o vue js en el futuro tiene una api familiar, basada en el existente editor concepto const editor = new editor({ plugins, value, onchange }) editor change(change => { }) sin embargo, también introduce métodos imperativos para facilitar las pruebas editor run('rendernode', props) editor event('onkeydown', event) editor command('addmark', 'bold') editor query('isvoid', node) ¡estoy muy emocionado por esto, así que espero que te guste! presentando el concepto de "comandos" anteriormente, los "métodos de cambio" se trataban de manera de primera clase, pero los plugins no tenían una forma fácil de agregar sus propios métodos de cambio que fueran reutilizables en otros lugares y no tenían forma de anular la lógica incorporada para ciertos comandos, por ejemplo splitblock o inserttext sin embargo, ahora todo esto es personalizable por plugins, con el plugin central de slate proporcionando todos los comandos predeterminados anteriores const plugin = { commands { wrapquote(change) { change wrapblock('quote') }, }, } esos comandos están disponibles directamente en los cambios objetos, que ahora son específicos del editor change wrapquote() esto te permite definir todos tus comandos en un solo lugar, fácilmente comprobable y luego, los plugins "comportamentales" pueden simplemente tomar los nombres de los comandos como opciones, para que tengas control total sobre la lógica que desencadenan presentando el concepto de "consultas" de manera similar a los comandos, las consultas permiten a los plugins definir comportamientos específicos que el editor puede consultar de manera reutilizable, para ser utilizados al renderizar botones, o decidir sobre comportamientos de comandos, etc por ejemplo, podrías definir una getactivelist consulta const plugin = { queries { getactivelist(editor) {}, }, } y luego poder reutilizar esa lógica fácilmente en diferentes lugares de tu base de código, o pasar el nombre de la consulta a un plugin que pueda usar tu lógica personalizada const list = change getactivelist() if (list) { } else { } tomados en conjunto, los comandos y las consultas ofrecen una mejor manera para que los plugins gestionen sus interdependencias pueden recibir nombres de comandos o consultas como opciones para cambiar sus comportamientos, o pueden exportar nuevos comandos y consultas que puedes reutilizar en tu base de código la pila de middleware ahora es diferible con la introducción del editor controlador, la pila de middleware en slate también ha sido actualizada cada middleware ahora recibe una siguiente función (similar a express o koa) que te permite elegir si iterar la pila o no // 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() } si bien eso puede parecer inconveniente, abre un comportamiento completamente nuevo, que es diferir a los plugins más adelante en la pila para ver si "manejan" un caso específico, y si no, manejarlo tú mismo function onkeydown(event, editor, next) { if (event key === 'enter') { const handled = next() if (handled) return handled // otherwise, handle `enter` yourself } } así es como toda la lógica central en slate react se implementa ahora, eliminando la necesidad de un plugin "antes" y un plugin "después" que duplican la lógica bajo el capó, el esquema , comandos y consultas se implementan como plugins que también adjuntan middleware variable por ejemplo, los comandos se procesan utilizando el oncommand middleware bajo el capó const plugin = { oncommand(command, editor, next) { } } esto te permite escuchar todos los comandos y anular comportamientos individuales si decides hacerlo, sin tener que anular el comando en sí esta es una característica muy avanzada, que la mayoría de las personas no necesitará, pero muestra la flexibilidad proporcionada al migrar toda la lógica interna personalizada previamente para basarse en la nueva pila de middleware los plugins ahora se pueden definir en arreglos anidados esta es una pequeña adición, pero significa que ya no necesitas diferenciar entre plugins individuales y múltiples plugins en un arreglo esto permite que los plugins se compongan más fácilmente a partir de otros múltiples plugins, sin que el usuario final tenga que cambiar la forma en que los utiliza pequeño, pero fomenta un poco más la reutilización desaprobado el simulador slate está desaprobado anteriormente, esto se usaba como un pseudo controlador para fines de prueba sin embargo, ahora con el nuevo editor como un concepto de primera clase, todo lo que el simulador podía hacer ahora se puede hacer directamente en la biblioteca esto debería facilitar mucho las pruebas en entornos que no son de navegador ruptura el valor objeto ya no está vinculado a cambios anteriormente, podías crear un nuevo cambio llamando a value change() y recuperar un nuevo valor con la re arquitectura para desacoplar adecuadamente el esquema, comandos, consultas y complementos de los modelos de datos centrales de slate, esto ya no es posible en su lugar, los cambios siempre se crean a través de una editor instancia, donde viven esos conceptos // instead of const { value } = this state const change = value change() this onchange(change) // you now would do this editor change(change => { const { value } = change }) a veces esto significa que necesitarás almacenar el ref del editor para poder acceder a su editor change método en tus componentes de react elimina el stack "modelo", a favor del nuevo editor anteriormente había un pseudo modelo llamado el stack que era de muy bajo nivel, y no realmente un modelo este concepto ahora se ha integrado en el nuevo editor controlador, que puede ser utilizado en cualquier entorno porque es solo javascript puro casi no había necesidad de usar directamente una stack instancia anteriormente, por lo que este cambio no debería afectar a casi nadie elimina el esquema "modelo", a favor del nuevo editor anteriormente había otro pseudo modelo llamado el esquema , que se utilizaba para contener la lógica de validación todas las mismas características de validación siguen disponibles, pero el antiguo esquema modelo ahora está integrado en el editor controlador también, en forma de un schemaplugin que no está expuesto elimina el schema isvoid y schema isatomic a favor de consultas anteriormente, estos dos métodos se utilizaban para consultar el esquema sobre el comportamiento de un nodo o decoración ahora estas mismas consultas son posibles utilizando el concepto de "consultas", y están disponibles directamente en el cambio objeto if (change isvoid(node)) { } la pila de middleware ahora debe continuar explícitamente, utilizando next anteriormente, devolver undefined de un middleware (generalmente) continuaría la pila hacia el siguiente middleware ahora, con el middleware tomando un next argumento de función debes decidir explícitamente continuar la pila llamando a next() tú mismo eliminar el historial modelo, a favor de comandos anteriormente había un historial modelo que almacenaba las pilas de deshacer/rehacer, y gestionaba el guardado de nuevas operaciones en esas pilas toda esta lógica se ha integrado en el nuevo concepto de "comandos", y las pilas de deshacer/rehacer ahora residen en value data esto tiene la ventaja de permitir que el comportamiento del historial sea completamente sobreescribible por plugins de usuario, lo cual no era una tarea fácil de gestionar antes los valores ya no pueden ser normalizados en la creación con el desacoplamiento del modelo de datos y la capa de plugins, las reglas del esquema ya no están disponibles dentro del valor modelo esto significa que ya no puedes recibir un valor "normalizado" sin tener acceso al editor y sus 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 si bien esto parece inconveniente, hace que los límites en la api sean mucho más claros y mantiene separados los conceptos inmutables y mutables este ejemplo de código específico se vuelve más largo, pero se eliminan las complejidades en otras partes de la biblioteca el cambio clase ya no se exporta los cambios ahora son específicos del editor, por lo que exportar el cambio clase ya no tiene sentido en su lugar, puedes usar el editor change() api para recibir un nuevo objeto de cambio con los comandos y consultas específicos de los plugins de tu editor el getclosestvoid , getdecorations y hasvoidparent método ahora toma un editor anteriormente, estos node métodos tomaban un schema argumento, pero esto ha sido reemplazado por el nuevo editor controlador ahora que el schema modelo ha sido eliminado 0 41 — 21 de septiembre de 2018 obsoleto el sinnormalización helper ha sido renombrado a sinnormalizar esto es para mantener la consistencia con los nuevos helpers para singuardar y sinfusionar rompiendo el concepto de "flags de operación" fue eliminado este era un concepto confuso que se implementó de múltiples maneras diferentes y llevó a que la lógica en torno a la normalización, guardado y fusión de operaciones fuera más compleja de lo que necesitaba ser estas flags han sido reemplazadas por tres funciones helper más simples sinnormalizar , singuardar y sinfusionar change withoutnormalizing(() => { nodes foreach(node => change removenodebykey(node key)) }) change withoutsaving(() => { change setvalue({ decorations }) }) esto significa que ya no usas el { normalize false } o { save false } opciones como argumentos para métodos de cambio individuales, y en su lugar usas estos nuevos métodos auxiliares para aplicar estos comportamientos a grupos de cambios a la vez los métodos de cambio "normalize" han sido eliminados anteriormente había un puñado de diferentes métodos de cambio de normalización como normalizenodebypath , normalizeparentbykey , etc estos eran confusos porque ponían la carga en el implementador para saber exactamente qué nodos necesitaban ser normalizados han sido eliminados, y los implementadores ya no necesitan preocuparse por qué nodos específicos normalizar, ya que slate se encargará de eso por ellos el interno refindnode y refindpath métodos han sido eliminados estos nunca debieron haber sido expuestos en primer lugar, y ahora ya no están presentes en el elemento interfaz estos solo se usaron internamente durante el proceso de normalización 0 40 — 22 de agosto de 2018 rompedor eliminar todas las rutas de código previamente desaprobadas esto ayuda a reducir parte de la complejidad en slate al no tener que manejar estas rutas de código más y ayuda a reducir el tamaño del archivo al actualizar, es altamente recomendable que primero actualices a la versión anterior y asegures que no hay advertencias de desaprobación siendo registradas, luego actualices a esta versión 0 39 — 22 de agosto de 2018 nuevo presentando el rango modelo y interfaz anteriormente, el concepto de "rango" se utilizaba en múltiples lugares diferentes, para la selección, para decoraciones y para actuar sobre rangos del documento esto funcionaba bien, pero ocultaba el sistema subyacente que es que rango es realmente una interfaz que otros modelos pueden elegir implementar ahora, seguimos utilizando el rango modelo para referenciar partes del documento, pero también puede ser implementado por otros modelos que necesiten adjuntar más significado semántico presentando la decoración y selección modelos estos dos nuevos modelos implementan la nueva rango interfaz donde anteriormente tenían que mal utilizar el rango modelo en sí con semánticas añadidas esto simplemente aclara parte de la confusión en torno a propiedades superpuestas y nos permite agregar incluso más métodos y propiedades específicos del dominio en el futuro sin problemas noticia de última hora ¡las decoraciones han cambiado! anteriormente, las decoraciones se basaban en el rango modelo, utilizando la propiedad existente de marcas y presentando su propia isatomic propiedad sin embargo, ahora se han separado en su propio modelo de decoración con una sola marca y con la isatomic propiedad controlada por el esquema lo que anteriormente habría parecido range create({ anchor { }, focus { }, marks \[{ type 'highlight' }], isatomic true, }) es ahora decoration create({ anchor { }, focus { }, mark { type 'highlight' }, }) cada decoración se asigna a un solo marcador objeto y la atomicidad del marcador se controla en el esquema en su lugar, por ejemplo const schema = { marks { highlight { isatomic true, }, }, } el rango modelo tiene una semántica reducida anteriormente, dado que todas las decoraciones y selecciones eran rangos, podías crear rangos con un isfocused , isatomic o marcadores propiedades ahora rango objetos son mucho más simples, ofreciendo solo un ancla y un foco , y pueden ser extendidos por otros modelos que implementan la interfaz de rango sin embargo, esto significa que usar rango create o document createrange podría no ser lo que deseas más por ejemplo, para crear una nueva selección, solías usar const selection = document createrange({ isfocused true, anchor { }, focus { }, }) pero ahora, necesitarás usar document createselection en su lugar const selection = document createselection({ isfocused true, anchor { }, focus { }, }) el value decorations propiedad ya no puede ser nula anteriormente, cuando no se aplicaban decoraciones al valor, la decoraciones propiedad se establecía en null ahora será un list vacío, para que la interfaz sea más consistente deprecated el node createchildren método estático está en desuso esto era solo un alias para node createlist y no era necesario puedes usar node createlist en adelante para el mismo efecto la renderportal propiedad de los plugins está en desuso esto permite que slate react sea ligeramente más delgado, ya que este comportamiento puede ser manejado en react 16 con el nuevo \<react fragment> usando la rendereditor propiedad en su lugar, de una manera que ofrece más control sobre el comportamiento del portal la data propiedad de los plugins está en desuso esta propiedad no estaba bien diseñada y eludía el principio fundamental de que todos los cambios en el valor del objeto fluirá a través de las operaciones dentro de change objetos se utilizaba principalmente para el estado de la capa de vista que debería manejarse con convenciones específicas de react para la gestión del estado en su lugar 0 38 — 21 de agosto de 2018 en desuso node isvoid el acceso está en desuso anteriormente, la "vaciedad" de un nodo estaba codificada en el modelo de datos pronto se determinará en tiempo de ejecución según el esquema de tu editor esta desuso solo asegura que no estés usando el node isvoid propiedad que no funcionará en futuras versiones lo que anteriormente habría sido if (node isvoid) { } ahora se convierte en if (schema isvoid(node)) { } esto requiere que tengas una referencia al schema objeto, que se puede acceder como value schema value isfocused/isblurred y value hasundos/hasredos están en desuso estas propiedades están fácilmente disponibles a través de value selection y value history en su lugar, y ahora están en desuso para reducir la complejidad y el número de diferentes formas de hacer las cosas 0 37 — 3 de agosto de 2018 nuevo presentando el punto modelo los rangos ahora se componen de dos punto modelos—un ancla y un foco —en lugar de tener las propiedades establecidas directamente en el rango mismo esto hace que el concepto de "punto" sea de primera clase en slate y se pueden construir mejores api alrededor de objetos punto point create({ key 'a', path \[0, 0], offset 31, }) estos puntos están expuestos en los rango objetos a través del ancla , foco , inicio y fin propiedades const { anchor, focus } = range change removenodebykey(anchor key) estos reemplazan a los anteriores anchorkey , anchoroffset , etc propiedades document createrange crea un rango relativo anteriormente tenías que usar range create y asegurarte de que pasabas argumentos válidos, y garantizar que "normalizabas" el rango para sincronizar sus claves y rutas esto ya no es el caso, ya que el createrange método lo hará por ti const range = document createrange({ anchor { key 'a', offset 1, }, focus { key 'a', offset 4, }, }) esto asegurará automáticamente que el rango haga referencia a nodos de texto hoja, y que sus anchor y focus rutas estén configuradas document createpoint crea un punto relativo al igual que el createrange método, createpoint creará un punto que está garantizado que es relativo al documento mismo esto a menudo es mucho más fácil que usar point create directamente const anchor = document createpoint({ key 'a', offset 1, }) rompedor el range focus método fue eliminado (no change focus !) esto fue necesario para dar paso a la nueva range focus propiedad point normalmente esto se habría hecho de una manera amigable para la migración como el resto de los cambios de método en esta versión, pero esta fue una excepción sin embargo, el change focus() método sigue disponible y funciona como se esperaba range set y range merge son peligrosos si anteriormente estabas utilizando los métodos de bajo nivel de immutable js range set o range merge con cualquiera de las propiedades de rangos que ahora han sido eliminadas, estas invocaciones fallarán en su lugar, deberías usar los range set ayudantes en adelante, que pueden ser migrados con advertencias de desaprobación en lugar de fallar directamente el offset propiedad de los puntos por defecto es null anteriormente por defecto era 0 pero eso podría ser confuso porque no hacía distinción entre un offset "establecido" o "no establecido" ahora por defecto es null en su lugar esto realmente no debería afectar ningún uso en el mundo real de slate la range tojson() estructura ha cambiado con la introducción de puntos, el rango ahora devuelve su anchor y focus propiedades como objetos json de punto anidados en lugar de directamente como propiedades por ejemplo { "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" \[] } obsoleto los shorts basados en selección en valor fueron obsoletos anteriormente podías acceder a cosas como anchorkey , startoffset y iscollapsed directamente en valor objetos esto resulta en una duplicación extra que es difícil de mantener con el tiempo, y difícil de entender para los recién llegados, sin mucho beneficio todas estas propiedades están obsoletas y deben ser accedidas en el value selection objeto directamente en su lugar los métodos de rango fueron estandarizados, con muchos obsoletos los métodos en rango objetos habían crecido drásticamente en tamaño muchos de ellos no tenían nombres consistentes, o se superponían de maneras innecesarias con la introducción de punto objetos, muchos de estos métodos podrían ser limpiados y su lógica delegada a los puntos directamente todos estos métodos siguen disponibles pero generarán advertencias de obsolescencia, facilitando la actualización hay una muy buena posibilidad de que solo estés usando un puñado de ellos en tu base de código de cualquier manera, todos ellos registrarán advertencias para un ejemplo de migración, consulta https //github com/ianstormtaylor/slate/pull/2035/commits/1bc560ab6242bc015c9f6d3bd20086f18849f8b7 aquí hay una lista completa de los métodos y propiedades que han sido desaprobados recientemente, y su nueva alternativa si 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 los cambios basados en la selección fueron estandarizados, con muchos obsoletos de manera similar a la rango de obsolescencias del método, la misma confusión y malas elecciones de nombres existieron en los cambio métodos que trataban con selecciones muchos de ellos han sido renombrados por consistencia, o se han vuelto obsoletos cuando existían alternativas todos estos métodos siguen disponibles pero generarán advertencias de obsolescencia, facilitando la actualización hay una muy buena posibilidad de que solo estés usando un puñado de estos métodos de cambio en tu base de código de cualquier manera, todos ellos registrarán advertencias para un ejemplo de migración, consulta https //github com/ianstormtaylor/slate/pull/2035/commits/1bc560ab6242bc015c9f6d3bd20086f18849f8b7 aquí hay una lista completa de los métodos que han sido cambiados y que ahora están en desuso, y su nueva alternativa si existe 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 de julio de 2018 urgente ¡las reglas del esquema han cambiado! para que puedan ser utilizadas en más casos (para que no tengas que recurrir a la más lenta validatenode/normalizenode función), la sintaxis de coincidencia para las reglas del esquema ha cambiado anteriormente, múltiples tipos/objetos se expresarían como { parent { types \['ordered list', 'unordered list'] }, } ahora hay un nuevo match concepto de objeto, que se ve así { parent { object 'block', type 'list' }, } los objetos de coincidencia pueden ser objetos, o un arreglo de objetos que actúa como o { parent \[{ type 'ordered list' }, { type 'unordered list' }], } además, las reglas del esquema ahora se pueden definir utilizando un schema rules arreglo de objetos con propiedades de coincidencia de nivel superior esto permite coincidir nodos de maneras que antes eran imposibles por ejemplo { schema { rules \[{ // match all blocks, regardless of type! match { object 'block' }, text / /g, normalize () => { }, }] } } todas las abreviaturas como schema blocks y schema inlines todavía están disponibles, y simplemente se reescriben a la sintaxis más flexible de rules bajo el capó estos cambios son solo una pequeña forma de hacer que slate sea más flexible para casos de uso avanzados cuando te encuentres con ellos la regla del esquema normalize ahora recibe slateerror objetos anteriormente se llamarían con una firma de (cambio, violación, contexto) ahora se llaman con (cambio, error) este nuevo error es un slateerror objeto con un error code y todas las mismas propiedades de contexto un normalizador que anteriormente se veía así { normalize (change, violation, context) { if (violation === 'child type invalid') { const type = index === 0 ? 'title' 'paragraph' return change setnodebykey(context child key, type) } } } ahora se vería así { normalize (change, error) { if (error code === 'child type invalid') { const type = index === 0 ? 'title' 'paragraph' return change setnodebykey(error child key, type) } } } esto es solo un intento de hacer que lidiar con errores de normalización sea un poco más idiomático con respecto a cómo se representan los errores en la mayoría de las bibliotecas, para no reinventar la rueda innecesariamente 0 35 — 27 de julio de 2018 nuevo rango objetos ahora mantienen un seguimiento de rutas, además de claves anteriormente, los rangos solo almacenaban sus puntos como claves ahora se utilizan tanto rutas como claves, lo que te permite elegir cuál es el más conveniente o el más eficiente para tu caso de uso se mantienen sincronizados por slate bajo el capó un nuevo conjunto de porruta métodos de cambio han sido añadidos todos los cambios que anteriormente podías hacer con un porclave cambio ahora también son compatibles con un porruta cambio del mismo nombre los cambios basados en rutas son a menudo más eficientes que los basados en claves las rutas ahora son de tipo lista https //facebook github io/immutable js/docs/#/list en lugar de array consulta la documentación de lista https //facebook github io/immutable js/docs/#/list por sus diferencias con array ( obtener método en lugar de indexación de array, tamaño en lugar de longitud , etc) última hora interno pero público nodo los métodos han sido cambiados hubo un puñado de métodos internos que no deberían ser utilizados en el 99% de las implementaciones de slate que se actualizaron o eliminaron esto se hizo en el proceso de simplificar muchos de los nodo métodos para hacerlos más consistentes y fáciles de usar para una lista de los afectados nodo assertpath fue cambiado anteriormente tenía un nombre confuso porque el equivalente nodo getpath hacía algo completamente diferente ahora deberías usar nodo assertnode(path) si necesitas este comportamiento nodo removedescendant fue eliminado no hay razón por la que debieras haber estado usando esto, ya que era un método no documentado y no utilizado que quedó de una versión anterior node updatenode , node insertnode , node removenode , node splitnode y node mergenode los métodos de mutación han sido cambiados todos tus cambios deben hacerse con operaciones, por lo que probablemente no estabas utilizando estos métodos internos han sido cambiados internamente para usar rutas deprecated el setkeygenerator y resetkeygenerator los ayudantes están obsoletos estos se usaban anteriormente para cambiar la lógica de generación de claves por defecto ahora puedes usar el equivalente keyutils setgenerator y keyutils resetgenerator en su lugar esto sigue el nuevo patrón de agrupar utilidades relacionadas en espacios de nombres únicos, como es el caso con el nuevo pathutils y textutils métodos internos pero públicos node han sido obsoletos hubo un puñado de métodos internos que no deberían ser utilizados en el 99% de las implementaciones de slate que fueron obsoletos para una lista de los afectados node getkeys y node getkeysasarray fueron desaprobados si realmente necesitas verificar la presencia de una clave, usa el nuevo node getkeystopathsobject en su lugar node aredescendantssorted y node isinrange fueron desaprobados estos se usaban para verificar si un nodo estaba en un rango, pero esto se puede hacer de manera más eficiente y más fácil con rutas ahora node getnodeatpath y node getdescendantatpath fueron desaprobados probablemente no estaban en uso por nadie, pero si los estabas usando, puedes usar los existentes node getnode y node getdescendant métodos en su lugar, que ahora aceptan rutas o claves 0 34 — 14 de junio de 2018 nuevo las decoraciones ahora pueden ser "atómicas" si estableces una decoración como atómica, se eliminará cuando se cambie, evitando que entre en un estado "parcial", lo cual puede ser útil para algunos casos de uso última hora los nodos de texto ahora representan su contenido como "hojas" anteriormente, su representación inmutable usaba una caracter por cada carácter ahora han cambiado para agrupar caracteres en hoja modelos, que se asemejan más a cómo se utilizan, y resulta en un montón de instancias de objetos inmutables flotando por ahí para la mayoría de las personas, esto no debería causar ningún problema, ya que este es un aspecto de bajo nivel de slate obsoleto el caracter modelo está obsoleto aunque el concepto de carácter todavía está en el repositorio por ahora, está obsoleto y se eliminará en una futura versión todo lo que resuelve se puede resolver con hojas en su lugar 0 33 — 21 de febrero de 2018 última hora los nodos vacíos ya no prescriben su contenido de texto anteriormente, los nodos vacíos normalizaban automáticamente su contenido de texto a un solo nodo de texto que contenía ' ' una cadena vacía de contenido esta restricción fue eliminada, para que los nodos vacíos puedan tener contenido arbitrario puedes usar esto para almacenar información en nodos vacíos de una manera que sea más consistente con los nodos no vacíos desaprobado el setblock método ha sido renombrado a setblocks esto es para dejar más claro que opera en cualquiera de los bloques actuales en la selección, no solo en un solo bloque el setinline método ha sido renombrado a setinlines por la misma razón que setblocks , para ser claro y mantener la consistencia 0 32 — 4 de enero de 2018 rompiendo la propiedad de los objetos slate ha sido renombrada a objeto esto es para reducir la confusión sobre la diferencia entre "kind" y "type" que son prácticamente sinónimos el nombre "objeto" fue elegido para coincidir con la api de stripe, ya que parece una elección sensata y se lee mucho mejor al mirar a través de json todas las razones de normalización que contienen kind también han sido renombradas anteriormente había cadenas de razones de normalización como child kind invalid este tipo de cadenas han sido renombradas a child object invalid para mantener la consistencia 0 31 — 16 de noviembre de 2017 nuevo se agregó un nuevo modelo de operación este modelo se utiliza para almacenar operaciones en la pila de historial y (de)serializarlas de manera consistente para casos de uso de edición colaborativa rompiendo los objetos de operación en slate ahora son registros inmutables anteriormente eran objetos de javascript nativos y mutables ahora, hay un nuevo modelo de operación en slate, asegurando que todos los datos dentro de value los objetos son inmutables y permite una fácil serialización de operaciones usando operation tojson() para cuando se envían entre editores esto no debería afectar a la mayoría de los usuarios, a menos que estés dependiendo de cambiar los valores de las operaciones de bajo nivel de slate (simplemente leerlos está bien) las listas de operaciones en slate ahora son listas inmutables anteriormente eran arreglos de javascript nativos y mutables ahora, para mantener la consistencia con otros usos inmutables, son listas inmutables esto no debería afectar a la mayoría de los usuarios 0 30 — 27 de octubre de 2017 rompiendo eliminar todos los caminos de código previamente desaprobados esto ayuda a reducir parte de la complejidad en slate al no tener que manejar estos caminos de código más y ayuda a reducir el tamaño del archivo al actualizar, es altamente recomendable que primero actualices a la versión anterior y asegures que no haya advertencias de desaprobación registradas, luego actualices a esta versión 0 29 — 27 de octubre de 2017 nuevo agregado el nuevo valor modelo para reemplazar estado el nuevo modelo es exactamente el mismo, pero con un nuevo nombre también hay un modelo de estado exportado que advierte cuando se usa, para facilitar la migración última hora la set state operación ha sido renombrada a set value esto no debería afectar a casi nadie, pero en caso de que estuvieras dependiendo de los tipos de operación de bajo nivel, necesitarás actualizar esto desaprobado el "estado" ha sido renombrado a "valor" en todas partes todas las referencias actuales se mantienen como desaprobaciones, por lo que deberías poder actualizar y ver advertencias registradas en lugar de ser recibido con un editor roto esto es para reducir la confusión entre el "estado" de react y el valor del editor de slate, y en un esfuerzo por imitar aún más las api nativas del dom 0 28 — 25 de octubre de 2017 nuevo estado los objetos ahora tienen un incrustado state schema propiedad esta nueva propiedad de esquema se utiliza para normalizar automáticamente el estado a medida que cambia, de acuerdo con el esquema actual del editor esto hace que la normalización sea mucho más fácil última hora el esquema los objetos en slate han cambiado! anteriormente, eran donde podías definir reglas de normalización, definir reglas de renderizado y definir reglas de decoración esto estaba sobrecargado y dificultaba otras mejoras ahora, el renderizado y la decoración se realizan a través de las funciones de plugin recién añadidas ( rendernode , rendermark , decoratenode ) y la validación se realiza ya sea a través de la función de plugin de menor nivel validatenode o a través de los nuevos schema objetos el normalize métodos de cambio ya no toman un schema argumento anteriormente tenías que mantener una referencia a tu esquema y pasarlo a los métodos de normalización cuando los llamabas dado que estado los objetos ahora tienen un incrustado state schema propiedad, esto ya no es necesario 0 27 — 14 de octubre de 2017 última hora el rango modelo ahora se llama hoja esto es para desambiguar con el concepto de "rangos" que se utiliza en todo el código para ser sinónimo de selecciones por ejemplo, en métodos como getblocksatrange(selection) el text ranges propiedad en la representación json ahora es text leaves al pasar json con text ranges ahora recibirás una advertencia de desaprobación en la consola en desarrollo desaprobado el selección modelo ahora se llama rango esto es para dejar más claro lo que realmente es una "selección", para que muchos de los otros métodos que actúan sobre "rangos" tengan sentido, y para paralelizar más de cerca la api nativa del dom para selecciones y rangos un objeto simulado de selección todavía se exporta con métodos estáticos desaprobados, para facilitar la transición a la nueva api el text getranges() método ahora es text getleaves() aún funcionará, y devolverá una lista de hojas, pero verás una advertencia de desaprobación en la consola en desarrollo 0 26 — 13 de octubre de 2017 última hora el decorar función de las reglas de esquema ha cambiado anteriormente, en decorar recibías un nodo de texto y el nodo coincidente, y tenías que agregar manualmente cualquier marca que quisieras a los caracteres del nodo de texto ahora, las "decoraciones" han cambiado para ser simplemente selección objetos con marcas en la selection marks propiedad en lugar de aplicar las marcas tú mismo, simplemente devuelves rangos de selección con las marcas a aplicar, y slate las aplicará internamente esto hace posible escribir comportamientos de decoración mucho más complejos consulta el ejemplo renovado de code highlighting https //github com/ianstormtaylor/slate/blob/master/examples/code highlighting/index js y el nuevo search highlighting https //github com/ianstormtaylor/slate/blob/master/examples/search highlighting/index js ejemplo para ver esto en acción el set data tipo de operación ha sido reemplazado por set state con la nueva state decorations propiedad, no tiene sentido tener un nuevo tipo de operación para cada propiedad de state objetos en su lugar, la nueva set state operación imita más de cerca la existente set mark y set node operaciones obsoleto nuevo ahora puedes establecer decoraciones basadas en información externa anteriormente, la lógica de "decoración" en slate siempre se basaba en el texto de un nodo y solo se volvería a renderizar cuando ese texto cambiaba ahora, hay una nueva state decorations propiedad que puedes establecer a través de change setstate({ decorations }) puedes usar esto para agregar marcas solo de presentación a rangos arbitrarios de texto en el documento consulta el nuevo search highlighting https //github com/ianstormtaylor/slate/blob/master/examples/search highlighting/index js ejemplo para ver esto en acción el setdata método de cambio ha sido reemplazado por setstate anteriormente, llamarías a change setdata(data) pero a medida que se introducen nuevas state propiedades, no tiene sentido necesitar agregar nuevos métodos de cambio cada vez en su lugar, el nuevo change setstate(properties) imita más de cerca el existente setmarkbykey y setnodebykey para lograr el comportamiento antiguo, puedes hacer change setstate({ data }) el preservestatedata opción de state tojson ha cambiado el mismo comportamiento ahora se llama preservedata en su lugar esto lo hace consistente con todas las opciones existentes, y la nueva preservedecorations opción también 0 25 — 21 de septiembre de 2017 última hora el insertblock método de cambio ya no reemplaza bloques vacíos anteriormente, si usabas insertblock y la selección estaba en un bloque vacío, lo reemplazaría ahora necesitarás realizar esa verificación tú mismo y usar el nuevo replacenodebykey método en su lugar el block create y inline create métodos ya no normalizan anteriormente, si usabas uno de ellos para crear un bloque o inline con cero nodos en él, automáticamente agregarían un único nodo de texto vacío como el único hijo esto era inesperado en ciertas situaciones, y si dependías de esto, ahora necesitarás manejarlo manualmente 0 24 — 11 de septiembre de 2017 nuevo slate ahora es un "monorepo" en lugar de un solo paquete, slate se ha dividido en paquetes individuales para que solo puedas requerir lo que necesitas, reduciendo el tamaño del archivo en el proceso, algunos módulos útiles que solían ser solo internos ahora están expuestos hay un nuevo slate hyperscript ayudante esto fue posible gracias al trabajo en slate sugar https //github com/gitbookio/slate sugar , que allanó el camino el slate prop types paquete ahora está expuesto anteriormente, este era un módulo interno, pero ahora puedes usarlo para agregar tipos de propiedades a cualquier componente o plugin que crees el slate simulator paquete ahora está expuesto anteriormente, esta era una utilidad de prueba interna, pero ahora puedes usarla en tus propias pruebas también actualmente es bastante básica, pero podemos agregarle más con el tiempo rompedor inmutable es ahora un parámetro dependencia de slate anteriormente era una dependencia regular, pero esto te impedía traer tu propia versión, o tendrías duplicación ¡necesitarás asegurarte de que lo instales! el html , plano y crudo los serializadores están divididos en nuevos paquetes anteriormente los importabas de slate pero ahora los importarás de slate html serializer y slate plain serializer y el crudo serializador que fue desaprobado ahora ha sido eliminado el editor y placeholder los componentes están divididos en un nuevo paquete específico de react anteriormente los importabas de slate pero ahora tú importas { editor } from 'slate react' en su lugar 0 23 — 10 de septiembre de 2017 nuevo los modelos de slate ahora tienen model fromjson(object) y model tojson() métodos estos métodos operan con la forma json canónica (que solía llamarse "crudo") de esta manera no necesitas importar un serializador para recuperar json, si tienes el modelo puedes serializar/deserializar los modelos también tienen tojs y fromjs alias esto es solo para coincidir con los objetos de immutable js, que tienen ambos métodos sin embargo, para slate, los métodos son equivalentes ruptura el isnative propiedad de estado ha sido eliminada anteriormente, esto se usaba por razones de rendimiento para evitar la re renderización, pero ya no es necesario esto realmente no debería afectar a la mayoría de las personas porque es raro que dependas de que esta propiedad exista deprecated el raw serializador ahora está obsoleto todo el concepto de "raw" está siendo eliminado, a favor de permitir que todos los modelos puedan serializar y deserializar a json por sí mismos en lugar de usar el raw serializador, ahora puedes usar el fromjson y tojson directamente en los modelos las opciones toraw para el plain y html serializadores ahora se llaman tojson esto es para mantener la simetría con la eliminación del concepto de "raw" en todas partes el conciso opción para la serialización json ha sido desaprobada! esta opción causa mucha fuga de abstracción porque significa que no hay una representación json canónica de los objetos tenías que trabajar con datos concisos o no concisos el html serializador ya no utiliza el conciso representación esto no debería ser un problema para nadie porque la manifestación principal de esto tiene un aviso de desaprobación con un parche en su lugar por ahora el defaultblocktype del html serializador ahora se llama defaultblock esto es solo para dejar más claro que no solo admite establecer el default tipo sino también datos y isvoid 0 22 — 5 de septiembre de 2017 nuevo el state activemarks devuelve la intersección de marcas en la selección anteriormente solo había state marks que devuelve marcas que aparecieron en cualquier carácter en la selección pero state activemarks devuelve marcas que aparecen en cada carácter en la selección, lo cual es a menudo más útil para implementar comportamientos estándar de editores de texto enriquecido noticias de última hora el serializador ahora añade saltos de línea entre bloques anteriormente, entre bloques el texto se unía sin ningún espacio, pero esto no era realmente útil ni lo que esperarías el togglemark ahora verifica la intersección de marcas anteriormente, alternar eliminaría la marca del rango si alguno de los caracteres en un rango no la tenía sin embargo, esto no era lo que hacían todos los demás editores de texto enriquecido, por lo que el comportamiento ha cambiado para imitar el comportamiento estándar ahora, si algún carácter en la selección tiene la marca aplicada, se añadirá primero al alternar el length propiedad de los nodos ha sido eliminada esta propiedad causaba problemas con el código como en lodash que verificaba la "similitud a un arreglo" simplemente buscando una length propiedad que era un número onchange ahora recibe un change objeto (anteriormente llamado transform ) en lugar de un state esto es necesario porque obliga a que todos los cambios estén representados por un único conjunto de operaciones de lo contrario, en este momento es posible hacer cosas como state transform() apply({ save false }) transform() apply() y resultar en la pérdida de la información de operación en el historial con ot, necesitamos que todas las transformaciones que puedan ocurrir sean expuestas y emitidas por el editor la nueva sintaxis se ve así onchange(change) { this setstate({ state change state }) } onchange({ state }) { this setstate({ state }) } de manera similar, los manejadores ahora reciben e, data, change en lugar de e, data, state en lugar de hacer return state transform() apply() los plugins ahora pueden actuar directamente sobre el objeto de cambio los plugins aún pueden return change si quieren romper la pila para continuar con otros plugins (cualquier != null valor romperá ) pero también pueden no devolver nada, y la pila aplicará sus cambios y continuará esto era previamente imposible la nueva sintaxis se ve así function onkeydown(e, data, change) { if (data key == 'enter') { return change splitblock() } } el onchange y on\[before]change los controladores ahora reciben change objetos anteriormente también recibirían un estado objeto, pero ahora reciben cambio objetos como el resto de la api del plugin la apply({ save }) opción ahora es estado cambio({ save }) en su lugar esta es la forma más fácil de usarlo, pero requiere que sepas si guardar o no de antemano si deseas usarlo en línea después de haber guardado algunos cambios, puedes usar el cambio setoperationflag('save', true) bandera en su lugar sin embargo, esto no debería ser necesario para el 99% de los casos de uso el undo() y redo() transformaciones no guardan por defecto anteriormente tenías que decir específicamente a estas transformaciones que no guardaran en el historial, lo cual era incómodo ahora no guardarán las operaciones que están deshaciendo/rehaciendo por defecto onbeforechange ya no se llama desde componentwillreceiveprops , cuando se pasa un nuevo estado como props al \<editor> componente esto causó muchos problemas de gestión de estado y era extraño en primer lugar porque pasar props resultaría en cambios que se disparan ahora es responsabilidad del componente padre no pasar objetos de estado mal formateados el método de cambio splitnodebykey ha cambiado a ser superficial anteriormente, se dividía profundamente a un desplazamiento pero ahora es superficial y se ha añadido otro método de cambio splitdescendantsbykey (con una firma diferente) para el comportamiento de división profunda esto es necesario porque las operaciones de división y unión se han cambiado para ser todas superficiales, lo cual es requerido para que se puedan escribir transformaciones operativas en ellas los bloques ya no pueden tener hijos "inline" y "block" mezclados se esperaba implícitamente que los bloques contuvieran solo nodos "text" e "inline", o solo nodos "block" los casos inválidos ahora son normalizados por el esquema central la forma de muchas operaciones ha cambiado esto era necesario para hacer que las operaciones fueran completamente invertibles sin ningún contexto adicional las operaciones nunca se expusieron realmente de una manera consumible, así que no detallaré todos los cambios aquí, pero siéntete libre de mirar el código fuente para ver los detalles todas las referencias a "unir" nodos ahora se llaman "fusionar" esto es para ser un poco más claro, ya que la fusión solo puede ocurrir con nodos adyacentes ya, y para tener un mejor paralelismo con "dividir", como en las células la operación ahora se llama merge node , y las transformaciones ahora son merge desaprobado el transform apply() método está desaprobado anteriormente, aquí es donde se guardaba en el historial, pero creó una convención incómoda que no era necesaria ahora las operaciones se guardan en el historial a medida que se crean con métodos de cambio, en lugar de esperar hasta el final puedes acceder al nuevo estado de un cambio en cualquier momento a través de change state 0 21 — 20 de julio de 2017 rompiendo el html serializador ahora utiliza domparser en lugar de cheerio anteriormente, el html serializador utilizaba la cheerio biblioteca para representar elementos en la lógica de reglas de serialización, pero cheerio era una dependencia muy grande ha sido eliminada, y el nativo del navegador domparser ahora se utiliza en su lugar todas las reglas de serialización html necesitarán ser actualizadas si estás trabajando con slate en el servidor, ahora puedes pasar un serializador personalizado al html constructor, utilizando la parse5 biblioteca 0 20 — 17 de mayo de 2017 rompiendo regresando null desde el html el serializador omite el elemento anteriormente, null y undefined tenían el mismo comportamiento de omitir la regla y probar el resto de las reglas ahora, si regresas explícitamente null se omitirá el elemento en sí 0 19 — 3 de marzo de 2017 última hora el filterdescendants y finddescendants métodos ahora son de profundidad primero esto no debería afectar a casi nadie, ya que generalmente no son las mejores cosas para usar por razones de rendimiento si tienes un caso de uso muy específico que necesita profundidad primero, (o incluso probablemente algo mejor), tendrás que implementarlo tú mismo desaprobado ¡algunos node métodos han sido desaprobados! hubo algunos métodos que se habían agregado con el tiempo que tenían nombres poco apropiados que han sido desaprobados y renombrados, y un puñado de métodos que ya no son útiles para la biblioteca principal que han sido desaprobados aquí hay una lista completa aredescendantsorted > aredescendantssorted gethighestchild > getfurthestancestor obtenerelhijounicopadremasalto > obtenerelancestrounicohijomaslejano concatenarhijos decorartextos filtrardescendientesprofundos encontrardescendienteprofundo obtenerhijosentre obtenerhijosentreincluyendo esdividirenrangoenlinea 0 18 — 2 de marzo de 2017 última hora el plugin render ahora se llama plugin renderportal esto es para dar paso al nuevo plugin render que ofrece un comportamiento similar a hoc, para que los plugins puedan aumentar el editor como deseen 0 17 — 27 de febrero de 2017 obsoleto ¡algunos métodos de selección han sido obsoletos! anteriormente había muchas inconsistencias en la nomenclatura y el manejo de los cambios de selección todo esto se ha limpiado, pero en el proceso algunos métodos han sido obsoletos aquí hay una lista completa de los métodos obsoletos y sus nuevas alternativas movetooffsets > moveoffsetsto moveforward > move moverhaciaatras > mover moverdesplazamientoancla > moverancla moverdesplazamientoenfoque > moverenfoque moverdesplazamientoinicio > moverinicio moverdesplazamientofin > moverfin extenderhaciaadelante > extender extenderhaciaatras > extender deshacer > deseleccionar ¡algunas transformaciones de selección han sido desaprobadas! junto con los métodos, las transformaciones basadas en selección también han sido reestructuradas, resultando en desaprobaciones aquí hay una lista completa de las transformaciones desaprobadas y sus nuevas alternativas movera > seleccionar moveraoffsets > moveroffsetsa moveradelante > mover moveratras > mover moveriniciooffset > moverinicio moverfinoffset > moverfin extenderadelante > extender extenderhaciaatras > extender invertirseleccion > invertir deshacerseleccion > deseleccionar deshacermarcas 0 16 — 2 de diciembre de 2016 última hora los nodos en línea ahora siempre están rodeados por nodos de texto anteriormente, este comportamiento solo ocurría para nodos en línea con isvoid true ahora, todos los nodos en línea siempre estarán rodeados por nodos de texto si no existen nodos de texto, se crearán nodos vacíos esto permite un comportamiento más consistente en slate y paridad con otras experiencias de edición 0 15 — 17 de noviembre de 2016 última hora la única clave generada ha cambiado anteriormente, slate generaba claves únicas que se veían como '9dk3' pero no eran muy resistentes a conflictos ahora las claves son cadenas simples de números autoincrementales, como '0' , '1' , '2' esto deja más claro que las claves son simplemente una forma conveniente de referenciar de manera única los nodos en el corto plazo de la vida de una única instancia en memoria de slate no están diseñadas para ser utilizadas para la unicidad a largo plazo se ha exportado una nueva setkeygenerator función que te permite pasar tu propio mecanismo de generación de claves si deseas asegurar la unicidad el raw serializador no preserva claves por defecto anteriormente, el raw serializador omitía claves cuando se le pasaba la opción terse true , pero las preservaba sin ella ahora siempre omitirá claves, a menos que pases la nueva preservekeys true opción esto refleja mejor que las claves son ids temporales en memoria las operaciones en el documento ahora actualizan la selección cuando es necesario esto no te afectará a menos que estuvieras haciendo algunas cosas muy específicas con transformaciones y actualizando selecciones en general, esto hace que sea mucho más fácil escribir transformaciones, ya que en la mayoría de los casos, las operaciones subyacentes actualizarán la selección como esperarías sin que tú hagas nada obsoleto ¡los métodos de acceso a nodos ya no aceptan que se les pase otro nodo! anteriormente, los métodos de acceso a nodos como node getparent podían recibir ya sea una clave en forma de cadena o un objeto node por razones de rendimiento, se está desaprobando el paso de un objeto node así que si tienes llamadas que se ven como node getparent(descendant) , ahora deberán escribirse como node getparent(descendant key) por ahora, lanzarán una advertencia y lanzarán un error en una versión posterior de slate 0 14 — 10 de septiembre de 2016 ruptura el deshacer y rehacer deben aplicarse! anteriormente, deshacer y rehacer eran casos especiales de tal manera que no requerían una apply() llamada, y en su lugar devolverían un nuevo estado directamente ahora esto ya no es el caso, y son como cualquier otra transformación las transformaciones ya no están expuestas en estado o nodo la api de transformaciones ha sido completamente reestructurada para estar compuesta por "operaciones" para el soporte de edición colaborativa como parte de esta reestructuración, las transformaciones ahora solo están disponibles a través de la state transform() api, y no están expuestas en los estado o nodo objetos como lo estaban antes los objetos de transformación son ahora mutables anteriormente transformación era un registro , pero ahora es un simple constructor esto se debe a que las transformaciones están inherentemente mutando su representación de un estado, pero esta decisión está https //github com/ianstormtaylor/slate/issues/328 la selección ahora puede ser "no establecida" anteriormente, una selección nunca podía estar en un estado "no establecido" donde el anchorkey o focuskey era nulo esto ya no es técnicamente cierto, aunque esto realmente no debería afectar a nadie en la práctica 0 13 — 15 de agosto de 2016 última hora el rendernode y rendermark propiedades han desaparecido! anteriormente, la representación de nodos y marcas se realizaba a través de estas dos propiedades del \<editor> , pero esto ha sido reemplazado por la nueva schema propiedad ¡consulta los ejemplos actualizados para ver cómo definir un esquema! ¡hay una buena posibilidad de que esto elimine código extra para la mayoría de los casos de uso! 😄 el renderdecorations propiedad ha desaparecido! la representación de decoraciones también ha sido reemplazada por la nueva schema propiedad del \<editor> 0 12 — 9 de agosto de 2016 última hora los data files ahora es una array anteriormente era un filelist objeto, pero necesitaba ser cambiado para agregar soporte completo para pegar y soltar archivos en todos los navegadores esto no debería afectarte a menos que dependieras específicamente de que fuera similar a un array en lugar de un verdadero array 0 11 — 4 de agosto de 2016 última hora ¡los nodos vacíos se renderizan implícitamente de nuevo! anteriormente, slate requería que envolvieras los renderizadores de nodos vacíos tú mismo con el componente de envoltura expuesto \<void> esto era para permitir el estilo de selección, pero se realizó un cambio para permitir que el estilo de selección se manejara en javascript ahora el \<void> envoltorio será renderizado implícitamente por slate, así que no necesitas preocuparte por ello, y la "vaciedad" solo necesita ser alternada en un lugar, el isvoid true propiedad de un nodo 0 10 — 29 de julio de 2016 última hora las marcas ahora se pueden renderizar como componentes anteriormente, la única forma admitida de renderizar marcas era devolviendo un objeto de estilo ahora puedes devolver un objeto de estilo, una cadena de nombre de clase o un componente react completo debido a esto, el dom se renderizará ligeramente diferente que antes, resultando en un extra \<span> al renderizar marcas que no son componentes esto no te afectará a menos que dependieras de la salida del dom por alguna razón 0 9 — 28 de julio de 2016 última hora ¡las envolturas y desenvolturas han cambiado las firmas de los métodos! anteriormente, pasabas tipo y datos como parámetros separados, por ejemplo wrapblock('code', { src true }) esto era inconsistente con otras transformaciones, y se ha actualizado de tal manera que se pasa un solo argumento de propiedades en su lugar así que ese ejemplo ahora podría ser wrapblock({ type 'code', { data { src true }}) aún puedes pasar una cadena de tipo como abreviatura, que será el caso de uso más frecuente, por ejemplo wrapblock('code') 0 8 — 27 de julio de 2016 última hora el onkeydown y onbeforeinput las firmas de los controladores han cambiado! anteriormente, algunos controladores de slate tenían una firma de (e, state, editor) y otros tenían una firma de (e, data, state, editor) ahora todos los controladores recibirán un data objeto—que contiene datos específicos de slate relacionados con el evento—aunque esté vacío esto es útil para la compatibilidad futura donde podríamos necesitar agregar datos a un controlador que anteriormente no tenía ninguno, y es más agradable para la consistencia el onkeydown nuevo del controlador data objeto contiene el nombre de la tecla , código y una serie de es propiedades para facilitar el trabajo con teclas de acceso rápido el onbeforeinput nuevo del controlador data objeto está vacío el utils exportación ha sido eliminada anteriormente, una key utilidad y la finddomnode utilidad estaban expuestas bajo el utils objeto la key ha sido eliminada en favor del data objeto pasado a onkeydown y luego finddomnode utilidad ha sido mejorada a una exportación nombrada de nivel superior, así que ahora necesitarás acceder a ella a través de import { finddomnode } from 'slate' los nodos vacíos ahora tienen permanentemente " " como contenido anteriormente, contenían una cadena vacía, pero esto no es técnicamente correcto, ya que tienen contenido y no deberían considerarse "vacíos" ahora tendrán un solo espacio de contenido esto realmente no debería afectar a nadie, a menos que estuvieras accediendo a esa cadena para la serialización los nodos en línea vacíos ahora son imposibles esto es para mantener la consistencia con el comportamiento nativo contenteditable , donde aunque técnicamente los elementos pueden existir, tienen un comportamiento extraño y nunca pueden ser seleccionados 0 7 — 24 de julio de 2016 noticia de última hora el raw serializador ya no es conciso por defecto! anteriormente, el raw serializador devolvería una representación "concisa" del documento, omitiendo información que no era estrictamente necesaria para deserializar más tarde, como la clave de los nodos por defecto, esto ya no sucede tienes que optar por este comportamiento pasando { terse true } como el segundo argumento de la deserializar y serializar métodos 0 6 — 22 de julio de 2016 última hora ¡los componentes vacíos ya no se renderizan implícitamente! anteriormente, slate envolvería automáticamente cualquier nodo con isvoid true en un \<void> componente pero hacer esto te impedía personalizar el envoltorio, como agregar un classname o style propiedad así que ahora debes renderizar el envoltorio tú mismo , y ha sido exportado como slate void esto, combinado con un pequeño cambio en la estructura del componente \<void> permite que el estado "seleccionado" de los nodos vacíos se renderice puramente con css basado en la \ focus propiedad de un \<void> elemento, que anteriormente https //github com/ianstormtaylor/slate/commit/31782cb11a272466b6b9f1e4d6cc0c698504d97f esto nos permite simplificar la lógica de manejo de selección, mejorando el rendimiento y reduciendo la complejidad data offset key ahora \<key> \<index> en lugar de \<key> \<start> \<end> esto no debería afectar a nadie, a menos que estuvieras confiando específicamente en ese atributo en el dom este cambio reduce en gran medida el número de re renderizados necesarios, ya que anteriormente cualquier carácter adicional causaría un cambio en cascada en el \<start> y \<end> desplazamientos de los rangos de texto posteriores 0 5 — 20 de julio de 2016 última hora node gettextnodes() ahora node gettexts() esto es solo para consistencia con los otros métodos existentes de node como getblocks() , getinlines() , etc y es agradablemente más corto 😉 node los métodos ahora lanzan antes durante estados inesperados esto no debería romper nada para la mayoría de las personas, a menos que un extraño caso límite estuviera pasando desapercibido anteriormente 0 4 — 20 de julio de 2016 última hora rendermark(mark, state, editor) ahora rendermark(mark, marks, state, editor) este cambio te permite renderizar marcas basadas en múltiples marcas presentes a la vez en un rango dado de texto, por ejemplo, usando una fuente personalizada bolditalic otf cuando el texto tiene tanto negrita y cursiva marcas 0 3 — 20 de julio de 2016 última hora transform unwrapblock() ahora desenvuelve selectivamente anteriormente, llamar a unwrapblock con un rango que representa un hermano del medio desenvuelve todos los hermanos, eliminando completamente el bloque de envoltura ahora, llamarlo con esos mismos argumentos solo moverá el hermano del medio hacia arriba en la jerarquía, preservando la anidación en cualquiera de sus hermanos este cambio hace que sea mucho más simple implementar funcionalidades como desenvuelve un solo elemento de lista, que anteriormente desenvuelve toda la lista 0 2 — 18 de julio de 2016 última hora transform mark() ahora es transform addmark() y transform unmark() ahora es transform removemark() los nuevos nombres hacen más claro que las transformaciones son acciones que se están realizando, y allanan el camino para agregar un togglemark conveniencia también 0 1 — 13 de julio de 2016 🎉