How is serialized state different than config storage? Is it per project or global? Under what conditions is it lost? I seem to lose state often.
I’ll try to summarize my understanding of both:
- Used to modify the behavior of a package (enable/disable features, etc.).
- Open to changes by the user.
- Shared between projects/window.
- Lost only if the user destroy its config.cson file.
- Should be considered as a trusted source.
- Used to speed up packages activation.
- Closed to changes by users (you are not supposed to access/edit the serialized state in storage).
- Are created by a package on a per project basis.
- Should never be considered as a source of trust (state data can help speed up a package startup but everything it relates to can have changed since the time it was serialized).
- You can lose states whenever the storage dir content is discarded (there’s probably some other case that lead to a loss of state)
Hope it helps
Ah, that why it seems to be lost all the time. I thought it was global.
I used it for storing the list of recently opened files in my view-tail-large-files package which was totally wrong. And I just used it wrong in a new package I’m about to publish.
So what is the recommended method of permanent global (per computer/user) state storage? I haven’t noticed anything in the docs or in this forum.
There isn’t a built-in method for doing that. I’m pretty sure someone asked this about their package too and I believe I recommended creating a new directory under
~/.atom for it.