Multistep/wizard forms I'm trying to create a multistep/wizard form for Drupal 8.


User fills in a first name, last name fields
Clicks on the next button
Fills out more information
Clicks on the submit button


There are currently many resources devoted to multistep or wizard forms for Drupal 7 like this one and this. 

On the other hand, I've had some trouble figuring out which is "Drupal" way of creating Drupal 8 multistep/wizard forms.

I did some research and figured there are several approaches:


Store values with the new configuration system
Use the wizard form interface (not in core yet)
Store values with drupal session object (not sure if that exists or not)


Are those valid approaches for Drupal 8?
The easiest way to do this is to use $form_state. In your formBuild() method, you have an if/else or switch based on something like $form_state['step'] and display different form elements. Then you either have the same in your submit callback or have multiple submit callbacks, that do something to an object in $form_state that you're building, change the step and set the $form_state['rebuild'] flag to TRUE.

There are a few downsides to that approach, which is why (among other reasons) the ctools form wizard was created. It can get complicated if you have multiple steps and have to define all of that in a single form function/class and everything happens in POST requests.

What the ctools form wizard does is group multiple, separate forms together and control the navigation from one to the other. You also use the ctools object cache to store your object instead of $form_state, because that is no longer shared across your forms.

While that system doesn't exist yet, the ctools object cache has been ported to 8.x and is now called user tempstore, available as a service: \Drupal::service('user.private_tempstore') (before 8.0-beta8 called user.tempstore). This is a layer on top of the expirable key value store that introduces ownership of stored data in there. So this is what powers the well known message in views that a different user is currently editing that view and it's locked for that reason. Another advantage over using $_SESSION for that is that your data only has to be loaded when needed, when you are editing 3 views, then using $_SESSION would mean that you have to load and carry them around on every single page request.

If you don't need that, then you could rely on the session or also directly put it in an expirable key value store ($form_state is stored there now as well, not a pseudo-cache as it was in 7.x).

The configuration system however isn't a good match. That is not meant for per-user content (or content at all) as it doesn't really scale to store thousands or tens of thousands of records and might make some assumptions to pre-load everything it might need on a given page request (not yet, but there is an issue to make that happen)