Hey thanks for the review!

render the back/next "submit" buttons based on the "step number" (which is currently missing but can be calculated easily using the provided options)

I tried today to find a solution which is nice but i did not succeed. If we have a next and a previous button there would be also the need of disabling the previous button when the current step number is 0 and maybe change the label of the next button when the current step number is the last step. All this requires some sort of wrapper class including a storage. (Which will be handled in UX) if you got any idea of how to achieve that i'd very happy!

I added some more helpers in view vars which makes rendering easier and also i added some options in order to allow navigate through steps. I also updated this PR description with an example of how to use the form in a controller.

After reviewing the PR description again following your latest update, it might be helpful to include an example with a DTO (+ validator constraints bound to the underlying object) as this aligns with the recommended approach for working with forms.

I like the idea and how we can configure the steps, but handling it from the controller still feels a bit complex IMO.

After reviewing the PR description again following your latest update, it might be helpful to include an example with a DTO (+ validator constraints bound to the underlying object) as this aligns with the recommended approach for working with forms.

Sure i can add that. Thats just gonna be a fee lines of code.

I like the idea and how we can configure the steps, but handling it from the controller still feels a bit complex IMO.

Well but all of that is implementation detail. Like which storage to use which steps to skip or add to your multistep type. Without an implementation of a storage its not possible to enhance the DX. Mainly we should not forget that the main reason for this PR is to have this available for a nice LiveComponent in symfony UX.

If you have any better idea of how to increase the developer experience feel free to tell. I honestly ran out of ideas because i tried a lot of different things today. And i always came to the same conclusion... storage, storage, storage 😅

Would this require a lot of work to implement the following (not in this PR of course)

• serialize / encode the data from previous steps
• sign it
• add a hidden field / textarea

Or is this "one" of the storages we're talking about ? Will there be any interface for the "storage" in symfony/form .. or we let entirely people implementing from scratch this part ?

Will there be any interface for the "storage" in symfony/form .. or we let entirely people implementing from scratch this part ?

We "started" with a storage imterface (and a session storage) when we build it for UX.
https://github.com/symfony/ux/blob/4c6a06576d30caf1b96a0ba2a66d0f896f767edb/src/LiveComponent/src/Storage/StorageInterface.php
https://github.com/symfony/ux/blob/4c6a06576d30caf1b96a0ba2a66d0f896f767edb/src/LiveComponent/src/Storage/SessionStorage.php

But in the meantime we figured Symfony has no place for a storage interface (except if we would create something like a storage-contract. But a storage-contract would only provide one interface, implementation like a SessionStorage/FilesystemStorage/RedisStorage/... would need to go into different components (SessionStorage in Framework? FilesystemStore in Filesystem? RedisStorage in ...)

Or are we open to add "storage" into Form?

Without an implementation of a storage its not possible to enhance the DX

What about adding a newFormFlow utility + a newDataStorageInterface to implement that abstraction?

Mainly we should not forget that the main reason for this PR is to have this available for a nice LiveComponent in symfony UX.

I think you raise an important point here. Introducing this type in the Symfony repo would mean designing it in a way that isn't strictly tied to the UX package, as not all users may be using UX packages like we do. It's essential to ensure that it works well for everyone.

Would this require a lot of work to implement the following (not in this PR of course)

* serialize / encode the data from previous steps* sign it* add a hidden field / textarea

We were thinking about implementing a hidden field containing the current state, but when the page is reloaded we'll lose the current state.

In our current example implementaion we're using the session, this is persistent across reloads (until the session is killed).
Would we need to serialize/deserialize and/or sign the data in that case?

What about adding a newFormFlow utility + a newDataStorageInterface to implement that abstraction?

Yes we could do that. As we already have the Interface. How do we do the implementation? Shall i require http foundation for the session?

I think you raise an important point here. Introducing this type in the Symfony repo would mean designing it in a way that isn't strictly tied to the UX package, as not all users may be using UX packages like we do. It's essential to ensure that it works well for everyone.

I agree on that. But isn't it usable without symfony ux yet? I mean it might be a bit more code to write but it would be already usable.

Regarding the storage where should i put it? Can you maybe help me on this one?

I would not be shocked if a "FormStepPersisterInterface" or "Loader" or something like this was added into Form 🤷

Like ChoiceLoaderInterface maybe ?

Or simply document the events and to plug itself to store the data.

We also can consider there is only one entity saved, partially at each step, and then nothing is really needed here ?

In our current example implementaion we're using the session, this is persistent across reloads (until the session is killed).
Would we need to serialize/deserialize and/or sign the data in that case?

I guess not, indeed! 👍

(documentation will maybe just need a warning regarding funnel forms with login or register in the way, as session is often reset then)

Yes we could do that. As we already have the Interface. How do we do the implementation? Shall i require http foundation for the session?

We shouldn't require the http foundation directly, take a look atRequestHandlerInterface mechanism (and their subclasses).

Regarding the storage where should i put it? Can you maybe help me on this one?

Let me play a bit with this proposal and I'll back next week with more details about it.

We also can consider there is only one entity saved, partially at each step, and then nothing is really needed here ?

If you concider that yes then the implementation would be Userland

For referencehttps://github.com/craue/CraueFormFlowBundle. I've used this bundle in several projects and found it suitable for most advanced cases. It's worth a look and a ping to@craue who has expertise on this topic.

@silasjoisten I suggest updating your example code to remove the usage ofOskarStark\Symfony\Http\Responder. An example using core APIs is more useful as the community will be familiar with them (and will help the documentation team)

For referencehttps://github.com/craue/CraueFormFlowBundle. I've used this bundle in several projects and found it suitable for most advanced cases. It's worth a look and a ping to@craue who has expertise on this topic.

Yea i have worked with it as well and i did not like the DX in it. It felt quite old and i mean its a common problem why shouldn't it be part of Symfony itself. Even if its just a simple form flow without skipping things.

For some cases yes you need a more complex form flow. but sometimes you want to have it in order to have a nice User experience in you Application.

What is the current state of this PR?
Do we need to do something, or are we waiting for something?

I tested the proposal as it is, and it feels like too much responsibility for the user to handle (in the current state). I'm not referring to the form step definition, which is already simple, but to the navigation and data storage part across steps. IMO, there should be a default implementation that handles that for us, not a UX but a Symfony one, flexible enough to be used with or without UX capabilities.

This is my current expectation for this feature (https://gist.github.com/yceruto/0fe65c8669016fe48f24c4e047ce7fb1):

• it should work with a DTO (including the current step property)

• the step validation should follow thevalidation_groups approach with constraints defined in the DTO, e.g.

  $resolver->setDefault('validation_groups',function (Options$options) {return ['Default',$options['current_step']];});

• default navigation buttons (back, next, submit) and an action-based navigation handling approach (rather than checking by the button name). For example, I might add a new "skip" button with a "next" action in one step, which skips validations.

• a customizable data storage strategy (probably through a form option) to persist the data between steps. The session strategy should be the default.

my two cents :) still looking forward to this feature 💘

Nicee gist you made there! I focus ghis weekend on this Pr. And try to make it as you expect :) i like your idea very much!

Comming from the initial UX repo PR :) nice one

If something like this land on sf/form I think it needs storage included otherwise it may be « hard/prone to error » to implement/handle and may lead to devland issues no?

Hi there! I'll get back to this topic next week with a complete alternative proposal that addresses the main implementation concerns (this one:#59548 (comment) and others mentioned).

I can't wait to share it with all of you!

Here we go#60212 !

I will close this one thank you@yceruto