Great idea! I've looked at the previous PR and could use it! One question came up: how can I jump back to a specific step without having to press the back button many times?
May the answer is can't by default. I solved this issue by keeping track of which valid step we are at and the url contains the step number (1..n), so I can generate a url for the previous steps, but I dont allow to go to not-yet-valid next steps.
I think I can see the points where I need to customize to achieve this.

how can I jump back to a specific step without having to press the back button many times?

Hey! take a look at thetestMoveBackToStep() test, it covers this case. It's possible via submit operation or manually using$flow->moveBack('step') directly.

Hey@yceruto, awesome to see this may become a native part of Symfony Forms!

I just had a quick look at the implementation and didn't find anything aboutUploadedFile (yet).
This was one of the big challenges we had to solve with CraueFormFlowBundle in combination withhttps://rekalogika.dev/file-bundle/file-upload-filepond, especially to make restore work (when going back to show the previously submitted files) and then to handle those if the step is submitted again.

It would be very helpful to have a default way the FormFlow can handle file uploads, but also to have some interface to interact with the full lifecycle of uploaded files, e.g. to decide where and how to store them, how to reference them inside form data, etc.

I think the lifecycle consists of the following steps:

1. Initial upload. I think it would be best to already store the file(s) to a temporary location on the filesystem and just work with references to them.
   In our case we use the Rekalogika file bundle to directly reference Files with our DoctrineMedia Entity (seehttps://rekalogika.dev/file-bundle/doctrine-entity andhttps://rekalogika.dev/file-bundle/working-with-entities) and then store the Media entity inside our Form Data.
2. "Restore" already uploaded file(s) when the user goes back to a step with a file upload field.
3. Handle resubmit, especially for file inputs withmultiple attribute. If the same step is submitted more then once, the following cases need to be handled:

• keep unchanged files
• delete files which were removed
• create newly uploaded files

4. Final submission. Maybe we want to move files from a temporary location to persistent storage.

Maybe file uploads are not as important for an initial implementation, but it's definitely a use case which should be thought about.

Feel free to ping me if you have any questions. Maybe I could even build a minimal demo of the current implementation we use in our project and share it with you.

1. I think it would be best to already store the file(s) to a temporary location on the filesystem and just work with references to them.

this would be incompatible with apps using a load balancer with several servers, as there is no guarantee that the next request goes to the same server behind the load balancer. Such case require storing uploads in a shared storage (for instance using a S3 bucket or similar storage)

1. I think it would be best to already store the file(s) to a temporary location on the filesystem and just work with references to them.

this would be incompatible with apps using a load balancer with several servers, as there is no guarantee that the next request goes to the same server behind the load balancer. Such case require storing uploads in a shared storage (for instance using a S3 bucket or similar storage)

You're very right, thanks for pointing this out. So it's especially important to have the possibility of handling those different cases. Maybe aFileUploadHandlerInterface could be introduced. I don't really like thedefault handling of CraueFormFlowBundle (storing files as base64 to the session), but also can't come up with a better approach which would be compatible with horizontal scaling.

I haven’t checked the file upload yet because I knew it would be a complicated topic, but I think using a custom action button (as explained above) will give you the flexibility to do custom things on your own.

One option is to create your ownnext action button with a dedicatedhandler where file uploads can be managed. Then, you can keep track of the uploaded files by saving the references in the DTO, which is preserved between steps.

Imagine you have adocuments step defined for files uploading. In your navigator form, you can define this new action:

$builder->add('upload', FormFlowActionType::class, ['include_if' => ['documents'],// the steps where this button will appear'handler' =>function (MyDto$data,ActionButtonInterface$button,FormFlowInterface$flow) {// handle files uploading here ... store them somewhere ... create references ...// $data->uploadedFiles = ... save references if we go back ...$flow->moveNext();    },]);

So, it’s up to you where to store the files, how to reference them in the DTO, and how to render them again if the user goes back to this step, just by looking into$data->uploadedFiles.

Think of FormFlow action buttons like mini-controllers with a focused job. The main controller handles the shared logic across all steps, while each action handler takes care of custom operations.

You can even use them for inter-step operations (like in the demo preview, where I showed how to add or remove skill items from aCollectionType). In those cases, the step stays the same, but the bound data gets updated, and the form is rebuilt when$flow->getStepForm() is called again, now with new data and form updated.

This part feels a bit like magic, but it’s a helpful one given how complex multistep forms can be.