Allow returning promises from StorageManager `.load` and `.store` methods
Thanks for your thoughts! Hopefully I'll have time to implement it this week
Read full answer below ↓Question
This would offer a more modern and clean API than the current callback based approach.
Proposed API:
editor.StorageManager.add('simple-storage', {
load: async keys => {
const result = await foo(keys)
return JSON.parse(result)
},
async store(data) {
const result = await bar(data)
return result
}
});
There are a few ways this could be implemented:
1. Detect if the load/save method is thenable, if so await
This would complicate the API and code a little as users would need to make a choice between using either the callback or Promise based approach. The upside to this though is that it would not be a breaking change.
A side effect of this API change would allow mixing and matching of approaches:
// An async load method and callback store method
editor.StorageManager.add('simple-storage', {
load: async keys => {
const result = await foo(keys)
return JSON.parse(result)
},
store(data, clb, clbErr) {
bar(data, err => {
if (err) return clbErr(err)
clb()
})
}
});
2. Switch to a Promise only StorageManager API
The big benefit of this is we would be encouraging a more best practice approach and the API would be far less complicated. Not having to support two slightly different APIs is also good for maintenance. Unfortunately it would be a breaking change and might be best paired with a Promise rollout across the whole library. There are other APIs that could do with supporting promises too, commands for example.
3. Add new methods asyncLoad and asyncStore
The user would need to choose to either use the callback-based load/store methods, or their promise-based async counterparts. To me, this seems like the worst of options 1 & 2.
I'd be happy to open a PR for this, but would be good to get thoughts on which approach is best before continuing :smile:
Answers (3)
Thanks for your thoughts! Hopefully I'll have time to implement it this week
Really cool feature request Tom, I'd totally appreciate a PR.
For sure I'd go with your first approach, not breaking the current API is always a goal to reach. Just adding the ability to create async-await enabled custom storage managers would be amazing. Later we might also update the built-in local and remote storages to work in that way.
Here an example of what I'd expect to work (to check also if storage events work correctly)
const asyncStorage = {};
editor.StorageManager.add('async-storage', {
async load(keys) {
return new Promise(res => {
setTimeout(() => {
res(keys.reduce((acc, key) => {
acc[key] = asyncStorage[key];
return acc;
}, {}))
}, 1000);
});
},
async store(data) {
return new Promise(res => {
setTimeout(() => {
for (let key in data) {
asyncStorage[key] = data[key];
}
res();
}, 1000);
});
}
});
This would complicate the API and code a little as users would need to make a choice between using either the callback or Promise based approach
A side effect of this API change would allow mixing and matching of approaches
I'd just care about updating the documentation here https://grapesjs.com/docs/modules/Storage.html#define-new-storage In this way, publicly, only the async-await will be visible
With the new StorageManager refactor this can be closed https://github.com/artf/grapesjs/pull/4223
Related Questions and Answers
Continue research with similar issue discussions.
Issue #3317
FEAT: Add support for promises to custom RTE API
What are you trying to add to GrapesJS? Support for richtext editors with promise based APIs. Describe your feature request detailed CKEdit...
Issue #3193
FEAT: Change of current internal object store to allow for relation mappings instead of current indexable container implementation
What are you trying to add to GrapesJS? Currently newly instantiated editor instances are added to a indexable collection where the user mu...
Issue #3639
[Feature]: Improve UndoManager API
One thing i think would add great functionality is a more detailed history stack. U can get the undo stack and build a sort of history repo...
Issue #3071
BUG: update listener triggered on initial load
Hello! I found weird bug with update listener. It's triggered on initial load if html code has <img> tag with class attribute: You can chec...
Paid Plugins That Match This Issue
Curated by issue keywords and label relevance to help you ship faster.
Loading paid plugin recommendations...
Check the open-source GrapesJS plugins on GitHub or run a quick search in our free catalog.
Browse free plugins →Premium plugins ship with support, regular updates, and production-ready features — save days of integration work.
Browse premium plugins →Related tutorials
In-depth guides on the same topic.
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
Browse Plugin Categories
Jump directly to plugin category pages on the marketplace.