Migrando

migrar de versiones anteriores de slate a la 0 50 x versiones no es una tarea sencilla todo el marco fue reconsiderado desde cero esto ha resultado en un mucho mejor conjunto de abstracciones, lo que resultará en que escribas menos código pero el proceso de migración no es simple se recomienda encarecidamente que después de leer esta guía, leas el original docid\ jvtijclhtp7xv ytfglpn y los otros docid 2hhy6vkqfiyrth y61pxl para ver cómo se aplican todos los nuevos conceptos diferencias principales aquí hay un resumen de las principales diferencias en la 0 50 x versión de slate desde un punto de vista arquitectónico ¡json! el modelo de datos ahora está compuesto por objetos json simples anteriormente, utilizaba https //immutable js github io/immutable js/ estructuras de datos este es un gran cambio, y uno que desbloquea muchas otras cosas con suerte, también aumentará el rendimiento promedio al usar slate también facilita mucho el inicio para los recién llegados este será un gran cambio del que migrar, pero valdrá la pena interfaces el modelo de datos se basa en interfaces anteriormente, cada modelo era una instancia de una clase ahora, no solo los datos son objetos simples, sino que slate solo espera que los objetos implementen una interfaz así que las propiedades personalizadas que solían estar en node data ahora pueden estar en el nivel superior de los nodos espacios de nombres se expone una gran cantidad de funciones auxiliares como una colección de funciones auxiliares en un espacio de nombres por ejemplo, node get(root, path) o range iscollapsed(range) esto termina haciendo que el código sea mucho más claro porque siempre puedes ver rápidamente con qué interfaz estás trabajando typescript la base de código ahora utiliza typescript trabajar con json puro como modelo de datos y usar una api basada en interfaces son dos cosas que se han facilitado al migrar a typescript no necesitas usarlo tú mismo, pero si lo haces, obtendrás mucha más seguridad al usar las apis (¡y si usas vs code, obtendrás una buena autocompletación de todos modos!) menos conceptos el número de interfaces y comandos se ha reducido anteriormente selección , anotación , y decoración solían ser clases separadas ahora son simplemente objetos que implementan la rango interfaz anteriormente bloque y en línea eran separados; ahora son objetos que implementan la elemento interfaz anteriormente había un documento y valor , pero ahora el nivel superior editor contiene los nodos hijos del propio documento el número de comandos también se ha reducido anteriormente teníamos comandos para cada tipo de entrada, como inserttext , inserttextatrange , inserttextatpath estos se han fusionado en un conjunto más pequeño de comandos más personalizables, por ejemplo, inserttext que puede tomar en ruta | rango | punto menos paquetes en un intento de disminuir la carga de mantenimiento, y porque la nueva abstracción y las api en los paquetes centrales de slate facilitan mucho las cosas, el número total de paquetes se ha reducido cosas como slate plain serializer , slate base64 serializer , etc han sido eliminados y pueden ser implementados en el espacio del usuario fácilmente si es necesario incluso el slate html deserializer ahora puede ser implementado en el espacio del usuario (en 10 loc aprovechando slate hyperscript ) y paquetes internos como slate dev environment , slate dev test utils , etc ya no están expuestos porque son detalles de implementación comandos se ha introducido un nuevo concepto de "comando" (los antiguos "comandos" ahora se llaman "transformaciones" ) este nuevo concepto expresa la intención semántica de un usuario editando el documento y permiten la abstracción adecuada para aprovechar los comportamientos del usuario; por ejemplo, para cambiar lo que sucede cuando un usuario presiona enter, o retroceso, etc en lugar de usar keydown eventos, deberías probablemente anular los comportamientos de comando en su lugar los comandos se activan llamando a las editor funciones centrales y viajan a través de una pila similar a middleware, pero construida a partir de funciones compuestas cualquier plugin puede anular los comportamientos para aumentar un editor plugins los plugins son ahora funciones simples que aumentan el editor objeto que reciben y lo devuelven nuevamente por ejemplo, pueden aumentar la ejecución de comandos al componer la editor exec función o escuchar operaciones al componer editor apply anteriormente, dependían de una pila de middleware personalizada, y eran solo bolsas de controladores que se fusionaban en un editor ahora estamos usando composición de funciones simples (también conocida como envoltura) en su lugar elementos la naturaleza de bloque y en línea es ahora una elección en tiempo de ejecución anteriormente, estaba integrada en el modelo de datos con el objeto 'bloque' o objeto 'en línea' atributos ahora, verifica si un "elemento" es en línea o no en tiempo de ejecución por ejemplo, podrías verificar que element type === 'enlace' y tratarlo como en línea más parecido a react el renderizado y el manejo de eventos ya no son una preocupación de los plugins anteriormente, los plugins tenían control total sobre la lógica de renderizado y manejo de eventos en el editor esto crea un mal incentivo para comenzar a poner toda la lógica de renderizado en plugins, lo que coloca a slate en una posición de ser un envoltorio alrededor de todo react, lo cual es muy difícil de hacer bien en cambio, la nueva arquitectura tiene plugins enfocados puramente en los aspectos de richtext, y deja los aspectos de renderizado y manejo de eventos a react contexto anteriormente, el \<editor> componente estaba cumpliendo doble función como una especie de objeto "controlador" y también el contenteditable elemento dom esto llevó a mucha incomodidad en cómo otros componentes trabajaban con slate en la nueva versión, hay un nuevo \<slate> proveedor de contexto y un \<editable> contenteditable como componente al colocar el \<slate> proveedor más arriba en tu árbol de componentes, puedes compartir el editor directamente con barras de herramientas, botones, etc usando el useslate gancho ganchos además del useslate gancho, hay un puñado de otros ganchos por ejemplo, el useselected y usefocused ganchos ayudan a saber cuándo renderizar estados seleccionados (a menudo para nodos vacíos) y dado que utilizan la api de contexto de react, se volverán a renderizar automáticamente cuando su estado cambie beforeinput ahora usamos el beforeinput evento casi exclusivamente en lugar de depender de una serie de adaptadores y las peculiaridades de los eventos sintéticos de react, ahora estamos utilizando el estandarizado beforeinput evento como nuestra base está completamente soportado en safari y chrome, pronto será soportado en el nuevo edge basado en chromium, y actualmente se está trabajando en firefox mientras tanto, hay algunos parches para hacer que firefox funcione internet explorer ya no es compatible en el núcleo de forma predeterminada sin historia la lógica de historial central ahora finalmente ha sido extraída en un plugin independiente esto facilita mucho a las personas implementar sus propios comportamientos de historial personalizados y asegura que los plugins tengan suficiente control para aumentar el editor de maneras complejas, porque el historial lo requiere sin marcas las marcas han sido eliminadas del modelo de datos de slate ahora que tenemos la capacidad de definir propiedades personalizadas directamente en los nodos, puedes modelar marcas como propiedades personalizadas de los nodos de texto por ejemplo, el negrita se puede modelar simplemente como un negrita true propiedad sin anotaciones de manera similar, las anotaciones han sido eliminadas del núcleo de slate ahora se pueden implementar completamente en el espacio del usuario definiendo operaciones personalizadas y renderizando rangos anotados utilizando decoraciones pero en la mayoría de los casos, se deberían usar propiedades de nodos de texto personalizadas o decoraciones de todos modos no había muchos casos de uso que se beneficiaran de las anotaciones reducciones uno de los objetivos era simplificar drásticamente mucha de la lógica en slate para facilitar su mantenimiento y evolución esto se logró refactorizando a mejores abstracciones base sobre las que se puede construir, aprovechando las apis modernas del dom y migrando a patrones de react más simples para darte una idea del cambio en el total de líneas de código slate 8,436 > 3,958 (47%) slate react 3,905 > 1,954 (50%) slate base64 serializer 38 > 0 slate dev benchmark 340 > 0 slate dev environment 102 > 0 slate dev test utils 44 > 0 slate history 0 > 211 slate hotkeys 62 > 0 slate html serializer 253 > 0 slate hyperscript 447 > 345 slate plain serializer 56 > 0 slate prop types 62 > 0 slate react placeholder 62 > 0 total 13,807 > 6,468 (47%) ¡es una gran diferencia! y eso ni siquiera incluye las dependencias que se eliminaron en el proceso también