The next system we will look at is the TempStore (temporary store).
The tempstore is a key/value, session-like storage system for keeping temporary data across multiple requests. Imagine a multistep form or a wizard with multiple pages as great examples of tempstore use cases. You can even consider "work in progress", that is, not yet permanently saved somewhere but kept in the tempstore so that a certain user can keep working on it until it's finished. Another key feature of the tempstore is that entries can have an expiration date, at which point they get automatically cleared. So that user had better hurry up.
There are two kinds of tempstore APIs: a private and a shared one. The difference between the two is that with the first one, entries strictly belong to a single user, whereas with the second one, they can be shared between users. For example, the process of filling in a multistep form is the domain of a single user, so the data related to that must be private to them. However, that form can also be open to multiple users, in which case the data can either be shared between the users (quite uncommon) or used to trigger a locking mechanism that blocks user B from making changes while user A is editing (much more common). So, there are many options, but we will see some examples soon.
First, though, let's look at some of the key players in this system.
We start with the PrivateTempStore class, which provides the API for dealing with the private tempstore. It is not a service, because in order to use it, we must instantiate it via the PrivateTempStoreFactory. So that is what we have to inject into our classes if we want to use it. The latter has a get($collection) method which takes a collection name that we decide upon and creates a new PrivateTempStore object for it. If you look closely, the storage it uses is based on the KeyValueStoreExpirableInterface, which is very similar to the KeyValueStoreInterface used by the State API. The only difference is that the former has an expiration date, which allows the automatic removal of old entries. By default, the storage used in Drupal 8 is the DatabaseStorageExpirable, which uses the key_value_expire table to store the entries.
Up to this point, the SharedTempStore is strikingly similar to the private one. It is instantiated using the SharedTempStoreFactory service and uses the same underlying database storage by default. The main difference is the namespace occupied in the key_value_expire table, which is composed by user.shared_tempstore.collection_name as opposed to user.private_tempstore.collection_name.
Additionally, when asking the factory for the SharedTempStore, we have the option of passing an owner to retrieve it for. Otherwise, it defaults to the current user (the logged-in user ID or the anonymous session ID). Also, the way we interact with it and its purpose, more than anything, differ.
So, let's take a look at how we can work with the private and the shared tempstores.