How pass three values input from a widget (block html) to another via a space-lua ? Claude produce many solutions but all are bad. I read this : “[Space-Lua] Prompt for input” but it seems not really adapt to my question.
Do you have an idea ?
I’m not exactly sure what you’re trying to accomplish, but if the goal is to have a widget that changes another widget, then you might want to store the state in the frontmatter or in an object somewhere. Then just call the system reload function to make the other widget re-render.
You can see an example of reading/writing values to the frontmatter here: silverbullet-libraries/Library/thepaperpilot/CBT-Journal/Tracker Section.md at main · thepaperpilot/silverbullet-libraries · GitHub
Yes. Its the goal. But i dont want to use the frontmatter for some esthetic raison. Because, the user is not familiar whith markdown, i wish to use some input html. So, this is the first widget.
After a clic on a button, the values are affected to 3 global variables accessibles for any space-value on any page. The second widget can then execute one action or not.
So, my question is : how script the button to do the job ?
Input is gonna be a bit sticky to write since you have to parse the page and check the block with the input.
The solution I reached here is to store interactive data in its own yaml file.
So a widget could do something like this:
function switchingButton()
widget.html(dom.buttom {
onclick = function()
state = yaml.parse(space.readPage("options.yaml"))
... do something with state here
space.writePage("options.yaml", yaml.stringify(state))
editor.invokeCommand("System: Reload")
end
}),
"switch state"
})
end
This is ok & performant in Silverbullet since everything is living on IndexedDB anyway… although each of these widgets would need to have a unique file / ref to write to.
Another route here is to write a regular JS component and install it as a codewidget plug.
you could use the client store to set and get different variables systemwide (but client dependent):
i used this in my OWM Widget Library, you can check it out as reference
1 Like
Thanks ! But why not datastore ? It looks pretty much the same, doesn’t it (and datastore has 3 additional functions : batch…) ? What are the differences ?
No idea 
. Because I haven’t got to DataStore yet 
clientStore is a wrapper around localstorage and dataStore is a more abstract wrapper around indexedDB. If you don’t need to efficiently query/set (i.e. not always having to read write the whole thing) stuff, clientStore is generally your better bet.
1 Like
Thanks ! I asked Claude about the differences between localstorage and indexedDB.
Differences between IndexedDB and LocalStorage
Storage Capacity
LocalStorage is limited to approximately 5-10 MB depending on the browser, which is suitable for small data like user preferences or authentication tokens.
IndexedDB offers much more space (typically several hundred MB, or even GB depending on the browser and available disk space), ideal for storing large amounts of data like product catalogs, offline data, or media files.
Data Types
LocalStorage only stores strings. You must serialize your objects with JSON.stringify() to save them and JSON.parse() to retrieve them.
localStorage.setItem('user', JSON.stringify({ name: 'Marie', age: 30 }));
const user = JSON.parse(localStorage.getItem('user'));
IndexedDB can directly store JavaScript objects, arrays, Blobs, Files, and other structured types without manual serialization.
API and Complexity
LocalStorage has a very simple synchronous API:
localStorage.setItem('key', 'value');
const value = localStorage.getItem('key');
localStorage.removeItem('key');
IndexedDB uses an event-based asynchronous API that is much more complex. You need to handle transactions, object stores, and callbacks:
const request = indexedDB.open('MyDatabase', 1);
request.onsuccess = (event) => {
const db = event.target.result;
const transaction = db.transaction(['store'], 'readwrite');
const store = transaction.objectStore('store');
store.add({ id: 1, name: 'Example' });
};
Performance and Search
LocalStorage offers no search or indexing capabilities. To find data, you must retrieve all content and manually search through it.
IndexedDB allows you to create indexes for fast and efficient searches on large amounts of data, with cursor support for iterating through results.
Recommended Use Cases
Use LocalStorage for:
- Saving simple user preferences
- Storing session tokens or identifiers
- Caching small amounts of text data
Use IndexedDB for:
- Progressive Web Apps (PWA) requiring offline functionality
- Storing complex data catalogs
- Managing large collections of objects with search capabilities
- Temporarily saving files or media
Transactions and Integrity
LocalStorage has no transaction system, which can cause problems if multiple operations need to be atomic.
IndexedDB offers a complete transaction system that guarantees data integrity, allowing you to commit or rollback multiple operations as a block.
In summary, LocalStorage is perfectly suited for simple and quick needs, while IndexedDB is designed for complex applications requiring a true client-side database system.
Can LocalStorage be used for a PWA?
Yes, LocalStorage can be used in a PWA, but with significant limitations that generally make it unsuitable as a primary offline storage solution.
LocalStorage Limitations for PWAs
Persistence not guaranteed: Browsers can clear LocalStorage without warning when disk space is limited or during automatic cleanup. For a PWA that needs to work offline reliably, this is problematic.
Insufficient capacity: With only 5-10 MB, you cannot store enough data for a complete offline experience (images, content, business data).
Blocking synchronous API: LocalStorage blocks the main thread during read/write operations, which can degrade your PWA’s performance, particularly on mobile devices.
No Service Worker support: Service Workers (essential for PWAs) cannot directly access LocalStorage. You must go through the main thread via postMessage(), which complicates the architecture.
Recommended Solutions for PWAs
Cache API: For storing static resources (HTML, CSS, JS, images) needed for offline functionality. This is the standard solution used by Service Workers.
IndexedDB: For dynamic and structured application data. It’s accessible from Service Workers and offers the necessary persistence.
Hybrid strategy: You can combine technologies according to your needs.
Cases Where LocalStorage Remains Acceptable in a PWA
LocalStorage can be suitable for:
- Non-critical user preferences (theme, language)
- Temporary flags or simple UI states
- Data easily retrievable from the server
But this data should never be essential to your PWA’s offline functionality.
Typical PWA Architecture Example
// Service Worker: Cache API for resources
self.addEventListener('fetch', (event) => {
event.respondWith(
caches.match(event.request)
.then(response => response || fetch(event.request))
);
});
// Service Worker: IndexedDB for data
self.addEventListener('sync', async (event) => {
const db = await openDB('myPWA');
// Synchronize data...
});
// Application: LocalStorage for preferences only
localStorage.setItem('theme', 'dark');
In summary, you can use LocalStorage in a PWA, but only for non-critical data. For a robust PWA with offline support, favor IndexedDB and Cache API.