Permitir la devolución de promesas desde los métodos '.load' y '.store' de StorageManager
¡Gracias por vuestras opiniones! Espero tener tiempo de implementarlo esta semana
Lee la respuesta completa abajo ↓Pregunta
Esto ofrecería una API más moderna y limpia que el enfoque actual basado en callback.
API propuesta:
'''javascript editor. StorageManager.add('simple-storage', { load: async keys => { resultado const = await foo(keys) return JSON.parse(resultat) }, async store(data) { resultado const = await bar(data) resultado de retorno } });
---
Hay varias formas de implementar esto:
## 1. Detecta si el método 'carga'/'guardar' es entonces posible; si es así, espera
Esto complicaría un poco la API y el código, ya que los usuarios tendrían que elegir entre usar el método de callback o el método basado en Promesa. La ventaja de esto es que no sería un cambio radical.
Un efecto secundario de este cambio en la API permitiría combinar enfoques:
'''javascript
Un método de carga asíncrona y método de almacenamiento de callback
editor. StorageManager.add('simple-storage', {
load: async keys => {
resultado const = await foo(keys)
return JSON.parse(resultat)
},
store(data, clb, clbErr) {
bar(data, err => {
si (err) return clbErr(err)
clb()
})
}
});
2. Cambiar a una API StorageManager solo Promise
El gran beneficio de esto es que estaríamos fomentando un enfoque más de buenas prácticas y la API sería mucho menos complicada. No tener que soportar dos APIs ligeramente diferentes también es bueno para el mantenimiento. Por desgracia, sería un cambio radical y quizá lo mejor se combinara con un despliegue de Promise en toda la biblioteca. Hay otras APIs que también podrían necesitar soportar promesas, comandos por ejemplo.
3. Añadir nuevos métodos 'asyncLoad' y 'asyncStore'
El usuario tendría que elegir entre usar los métodos basados en callbacks de 'carga'/'almacenamiento', o sus equivalentes asincrónicos basados en promesas. Para mí, esto parece la peor de las opciones 1 y 2.
Estaría encantado de abrir un récord permanente por esto, pero sería bueno conocer opiniones sobre cuál enfoque es el mejor antes de continuar :sonríe:
Respuestas (3)
¡Gracias por vuestras opiniones! Espero tener tiempo de implementarlo esta semana
Muy buena petición de función, Tom, agradecería mucho un reparto personal.
Sin duda yo optaría por tu primer enfoque, no romper la API actual siempre es un objetivo a alcanzar. Simplemente añadir la posibilidad de crear gestores de almacenamiento personalizados habilitados con async await sería increíble. Más adelante también podríamos actualizar los almacenes 'locales' y 'remotos' integrados para que funcionen de esa manera.
Aquí tienes un ejemplo de lo que esperaría que funcionara (para comprobar también si eventos de almacenamiento funcionan correctamente) '''js const asyncStorage = {};
editor. StorageManager.add('async-storage', { async load(keys) { return new Promise(res => { setTimeout(() => { res(keys.reduce((acc, key) => { acc[key] = asyncStorage[key]; Retorno de la ACC; }, {})) }, 1000); }); }, async store(data) { return new Promise(res => { setTimeout(() => { for (let key in data) { asyncStorage[clave] = datos[clave]; } res(); }, 1000); }); } });
> Esto complicaría un poco la API y el código, ya que los usuarios tendrían que elegir entre usar el callback o el enfoque basado en Promise
> Un efecto secundario de este cambio en la API permitiría combinar enfoques
Yo solo me preocuparía por actualizar la documentación aquí https://grapesjs.com/docs/modules/Storage.html#define-new-storage De este modo, públicamente, solo será visible el async-await
Con la nueva refactorización de StorageManager esto puede cerrarse https://github.com/artf/grapesjs/pull/4223
Preguntas y respuestas relacionadas
Continúa investigando con debates sobre temas similares.
Issue #3317
HAZAÑA: Añadir soporte para promesas de API RTE personalizada
¿Qué intentas añadir a GrapesJS? Soporte para editores de texto enriquecido con APIs basadas en promesas. Describe tu solicitud de función...
Issue #3193
LOGRO: Cambio del almacenamiento interno actual de objetos para permitir mapeos de relaciones en lugar de la implementación actual de contenedor indexable
¿Qué intentas añadir a GrapesJS? Actualmente, las instancias de editor recién instanciadas se añaden a una colección indexable donde el usu...
Issue #1909
SetComponents a veces es muy lento
Hola a todos, Estamos trabajando en una aplicación de boletín y usamos grapesjs como editor de correo con el preajuste del boletín PLGUIN y...
Issue #3654
[PREGUNTAS] editor.setComponents(html) y pageManager.select(pageId) no cargan los scripts js
Hola, @artf Como he leído, allowScripts:1 permite a grapesjs cargar scripts . Cuando cargo una página de aterrizaje por primera vez funcion...
Plugins de pago que cumplen con este problema
Seleccionado por temas clave y relevancia de etiquetas para ayudarte a enviar más rápido.
Cargando recomendaciones de plugins de pago...
Consulta los plugins de código abierto de GrapesJS en GitHub O haz una búsqueda rápida en nuestro catálogo gratuito.
Explora plugins gratuitos →Los plugins premium incluyen soporte, actualizaciones regulares y funciones listas para producción — ahorrando días de trabajo de integración.
Explora plugins premium →Tutoriales relacionados
Guías detalladas sobre el mismo tema.
Tutorial
Super Tooltip for GrapesJS — Version 0.1.5 Released 🎉
We’re excited to announce the v 0.1.5 update of Super Tooltip, our floating‑menu and tooltip plugin for GrapesJS
Tutorial
GrapesJS in 2026: The Complete Guide to the Open-Source Web Builder Framework
Master GrapesJS in 2026. Architecture, code examples, React integration, plugin development, Studio SDK, and how it compares to other projects
Explorar categorías de plugins
Ve directamente a las páginas de categorías de plugins en el marketplace.