ConverseJS : is there a way to not store data in localStorage?

[JohnXLivingston]

When in developing, localStorage cache can cause troubles.
Is there a way to not store anything?
At least use sessionStorage ?

Can there be problems in productions instances?

[jcbrand]

What is the issue you're running into?

I've done some work recently to make IndexedDB a viable alternative to localStorage, but you'll have to use a build from the current master branch, there is no release for it yet.

The master branch is however relatively stable and used in production.

[JohnXLivingston]

Thanks for your reply.
I made this issue as a TODO. I'm not sure that it is really a problem for now. I have to ensure that peertube will not have problem sharing the localStorage with another app (Peertube is supposed to be alone on the domain).

[jcbrand]

Converse prefixes everything that gets saved in localStorage, so it's unlikely to cause issues.

However, you can run into a situation where localStorage fills up, which is why I added support for IndexedDB.

[JohnXLivingston]

Converse prefixes, but peertube don't. I need to check Peertube's code.
And I have some side effect when I change Prosody config, due to ConverseJS data in localStorage.
Nothing Serious.

And I plan to use muc_mam to keep room history. So I don't know if i really need ConverseJS to keep data, such as chat history (it is difficult for me, when I develop, to know if messages displayed after a refresh comes from ConverseJS or from the server).

[jcbrand]

Converse caches chat data so that when you reload you don't have to query the XMPP server again. For some sites it's not a big deal to query the XMPP server again, but for others it's not an option because the page can load many times per minute.

@XaviFP worked on creating a store for Converse that doesn't persist any chat data, but it never got merged:
conversejs/converse.js#2356

Perhaps it could still be salvaged. If you used that, then messages would always be fetched from the XMPP server on page reload.

[JohnXLivingston]

Thanks for the link! That's interesting.