[LiveComponent] Adds MultiStep Form Feature #2433

silasjoisten · 2024-12-07T21:23:14Z

Q	A
Bug fix?	no
New feature?	yes
Issues	-
License	MIT

This pull request introduces a new feature to Symfony UX LiveComponent that enables developers to easily create multistep forms in their applications. This functionality simplifies the implementation of complex, multi-step workflows while maintaining a clean and structured developer experience.

Key Features

MultiStep Form Type (MultiStepType): A custom form type that handles step-specific configuration, such as defining the steps and their corresponding fields.
ComponentWithMultiStepFormTrait: A reusable trait to manage the form flow, including:
- Navigation between steps (next, previous, submit).
- Validation and data persistence for each step.
- Easy integration with storage mechanisms.
- Storage Interface (StorageInterface): Provides a standardized way to persist form state across steps, enabling seamless navigation and data retrieval.

Example Usage

Create the LiveComponent

<?php

declare(strict_types=1);

namespace App\Twig\Component;

use Symfony\UX\LiveComponent\Storage\StorageInterface;
use Symfony\UX\LiveComponent\ComponentWithMultiStepFormTrait;
use App\Form\Test\MyFancyWizardType;
use Symfony\Component\Form\FormFactoryInterface;
use Symfony\UX\LiveComponent\Attribute\AsLiveComponent;

#[AsLiveComponent(
    name: 'SuperFancyWizard',
    template: 'components/super_fancy_wizard.html.twig',
)]
final class WizardComponent
{
    use ComponentWithMultiStepFormTrait;

    public function __construct(
        private StorageInterface $storage,
        private FormFactoryInterface $formFactory,
    ) {
    }

    public function onSubmit(): void
    {
        $data = $this->getAllData();

        // Do what ever you want with the data.

        $this->resetForm();
    }

    protected static function formClass(): string
    {
        return MyFancyWizardType::class;
    }

    protected function getFormFactory(): FormFactoryInterface
    {
        return $this->formFactory;
    }

    protected function getStorage(): StorageInterface
    {
        return $this->storage;
    }
}

Create the FormType using getParent to Create a custom MultiStep form type:

<?php

declare(strict_types=1);

namespace App\Form;

use Symfony\UX\LiveComponent\Form\Type\MultiStepType;
use Symfony\Component\Form\AbstractType;
use Symfony\Component\Form\Extension\Core\Type\CheckboxType;
use Symfony\Component\Form\Extension\Core\Type\NumberType;
use Symfony\Component\Form\Extension\Core\Type\TextType;
use Symfony\Component\Form\FormBuilderInterface;
use Symfony\Component\OptionsResolver\OptionsResolver;
use Symfony\Component\Validator\Constraints\IsTrue;
use Symfony\Component\Validator\Constraints\NotBlank;

final class MyFancyWizardType extends AbstractType
{
    /**
     * @return class-string<AbstractType>
     */
    public function getParent(): string
    {
        return MultiStepType::class;
    }

    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver->setDefaults([
            'steps' => [
                'general' => static function (FormBuilderInterface $builder): void {
                    $builder
                        ->add('age', NumberType::class, [
                            'label' => 'Age',
                            'constraints' => [
                                new NotBlank(),
                            ],
                        ])
                        ->add('name', TextType::class, [
                            'label' => 'Name',
                            'constraints' => [
                                new NotBlank(),
                            ],
                        ]);
                },
                'contact' => static function (FormBuilderInterface $builder): void {
                    $builder
                        ->add('email', TextType::class, [
                            'label' => 'E-Mail',
                            'constraints' => [
                                new NotBlank(),
                            ],
                        ])
                        ->add('newsletter', CheckboxType::class, [
                            'label' => 'Newsletter',
                            'constraints' => [
                                new IsTrue(),
                            ],
                        ]);
                },
                'bar' => static function (FormBuilderInterface $builder): void {
                    $builder
                        ->add('address', TextType::class, [
                            'label' => 'Address',
                            'constraints' => [
                                new NotBlank(),
                            ],
                        ])
                        ->add('city', TextType::class, [
                            'label' => 'City',
                            'constraints' => [
                                new NotBlank(),
                            ],
                        ]);
                },
            ],
        ]);
    }
}

<div {{ attributes }}>

    <div class="max-w-4xl mx-auto">
        {% for stepName in this.stepNames %}
            <div class="inline-flex space-x-4">
                <span class="{% if stepName == this.currentStepName %}text-red-500{% else %}text-gray-400{% endif %}">{{ stepName }}</span>
                {% if not loop.last %}
                    /
                {% endif %}
            </div>
        {% endfor %}

        {{ form(form) }}
    </div>

    <div class="max-w-4xl mx-auto my-12">
        <button
            {{ live_action('previous') }}
            type="button"
            class="btn-secondary"
            {% if this.isFirst() %}disabled="disabled"{% endif %}
        >
            Previous
        </button>

        {% if not this.isLast() %}
            <button
                {{ live_action('next') }}
                type="button"
                class="btn-primary"
            >
                Next
            </button>
        {% else %}
            <button
                {{ live_action('submit') }}
                type="button"
                class="btn-primary"
            >
                Finish
            </button>
        {% endif %}
    </div>
</div>

Create a template and benefit from awesome methods to control the MultiStep form

Acknowledgments

This feature was collaboratively developed during the #SymfonyHackday following SymfonyCon Vienna 2024. Special thanks to the contributors for their outstanding work:

Your efforts and dedication have made this feature possible!

Still on my todo list:

Write tests
Update docs
Update CHANGELOG.md

Look and feel

seb-jean · 2024-12-07T21:40:26Z

Hello, thank you very much for your contribution: the idea is very interesting.
I don't know if it's already done but is there a possibility to stay on the page of the current step when you refresh the page or does it go back to step 1?

silasjoisten · 2024-12-07T21:53:03Z

Hello, thank you very much for your contribution: the idea is very interesting.

I don't know if it's already done but is there a possibility to stay on the page of the current step when you refresh the page or does it go back to step 1?

Hello, there is a Storage used which allows you by default to stay on the same step on page reload. So there is the persistence level already included

seb-jean · 2024-12-07T21:54:10Z

Nice!

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

OskarStark · 2024-12-07T22:07:08Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+        return u(static::class)
+            ->afterLast('\\')
+            ->snake()
+            ->toString();


Suggested change

return u(static::class)

->afterLast('\\')

->snake()

->toString();

return u(static::class)->afterLast('\\')->snake()->toString();

And is symfony/string still a requirement ?

yes i required it.

Is this the only place where it is needed? In this case it is preferred to not use a dep but use plain vanilla PHP for it

src/LiveComponent/src/Storage/StorageInterface.php

src/LiveComponent/src/Form/Type/MultiStepType.php

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

WebMamba · 2024-12-08T10:57:32Z

Hey @silasjoisten ! Thanks for this nice contribution ! You bring something that can be truly useful for a lot of folks! I just don't thinks that a trait in the LiveComponent component is the right place... I think we bring to much that are not LiveComponent related: StorageInterface, MultiStepType, and so on. I am also scared also that doing this in to a Trait can limit us in to the implementation and on the DX. I think we can go way further on this topics and bring features that can be also front end related (step transition).
So I am not sure where is the right place to put this work, should it be a new component ? A new documentation ? A Cookbook ?
Tell me what do you thinks about that cheers!
Thanks again 😁

silasjoisten · 2024-12-08T11:28:25Z

Hey @WebMamba,

Thanks for your detailed feedback and for taking the time to review this! 😊

I firmly believe that this feature fits well within the Symfony UX LiveComponents component. Here’s why:

Alignment with Existing Architecture:
The multistep form concept is built on the same principles as LiveComponents: reactive, state-driven interfaces that rely on server-side logic to manage component behavior. The StorageInterface and MultiStepType were specifically designed to integrate seamlessly into the LiveComponent ecosystem. Much like ComponentWithFormTrait, which manages forms within LiveComponents, this trait extends that functionality to handle multistep forms without introducing unnecessary complexity.
CollectionType as an Example:
Consider how Symfony provides the CollectionType as part of its Form component. It’s a focused feature, but it belongs there because it enhances the developer experience for managing collections within forms. Similarly, multistep forms naturally fit within LiveComponents because they extend its reactive capabilities.
DX and Limitations:
You mentioned that this approach might limit DX or implementation options. Could you elaborate on specific scenarios where you think this might be restrictive? For instance, LiveComponents already allows for tight integration of server-side logic, storage, and frontend rendering. How would moving this feature to another component, cookbook, or package better serve the DX? From my perspective, centralizing this within LiveComponents provides developers with a familiar and consistent experience, reducing the need to integrate external solutions or reinvent the wheel.
Future Enhancements:
While this implementation focuses on server-side management, it lays a strong foundation for frontend-related features like step transitions. Since LiveComponents already facilitates reactive UI updates, extending this feature to include frontend transitions feels like a natural progression within this component.

I’d love to hear your thoughts on these points and where you see potential challenges or conflicts. If you have specific ideas for improving or repositioning the feature, I’m happy to collaborate further.

Cheers,
Silas

smnandre · 2024-12-10T23:08:59Z

Hi @silasjoisten! So happy to see you there ❤️

First, thank you very very much for this PR! This feature will be warmly welcomed by many users.

Regarding the "where", it is now pretty clear, in my mind, that we will end up with a dedicated "LiveForm" or "UxForm" component/bundle.. probably sooner than later. But right now, we have... LiveComponent :)

Also, I do agree with you regarding the similarity with CollectionType + the DX aspects.

As i see it, we can introduce it in "experimental" anywhere we want, and we'll see until that where it best fits in UX 3.

Next comments in the code :)

I need to sleep on the "StorageInterface" thing because i'm having mixed feeling about introducing a generic tool like this for now, while we're moving things around here.

smnandre · 2024-12-10T23:09:55Z

src/LiveComponent/composer.json

@@ -51,6 +51,7 @@
        "symfony/serializer": "^5.4|^6.0|^7.0",
        "symfony/twig-bundle": "^5.4|^6.0|^7.0",
        "symfony/validator": "^5.4|^6.0|^7.0",
+        "symfony/string": "^5.4|^6.0|^7.0",


Can we remove it ( if only used for the string/camel stuff ?)

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

src/LiveComponent/src/Form/Type/MultiStepType.php

smnandre · 2024-12-10T23:27:14Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+            ->setDefault('current_step_name', static function (Options $options): string {
+                return array_key_first($options['steps']);
+            })
+            ->setRequired('steps');


Will require more checks

What checks you got in mind?

smnandre · 2024-12-10T23:30:21Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+    public function configureOptions(OptionsResolver $resolver): void
+    {
+        $resolver
+            ->setDefault('current_step_name', static function (Options $options): string {


Let's discuss this more globally, but i think "current_step" or even "step" could be enough, and improve readability.

Maybe just me, but i feel the implementation choice (e.g., passing the steps as a map) should not impose constraints on the overall naming convention.

wdyt ?

smnandre · 2024-12-10T23:32:58Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+    {
+        $view->vars['current_step_name'] = $options['current_step_name'];
+        $view->vars['steps_names'] = array_keys($options['steps']);
+    }


Suggested change

}

}

public function getBlockPrefix(): string

{

return 'multistep';

}

smnandre · 2024-12-10T23:33:50Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+
+    public function buildForm(FormBuilderInterface $builder, array $options): void
+    {
+        $options['steps'][$options['current_step_name']]($builder);


This should be checked first i guess ? 😅

I dont think so, because configure options is already ensuring that. (see the test)

I may miss-read this, but to me at this point there is no certitude that $options['steps'][$options['current_step_name']] is a callable that accept FormBuilderInterface argument ?

smnandre · 2024-12-10T23:36:33Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+        $view->vars['current_step_name'] = $options['current_step_name'];
+        $view->vars['steps_names'] = array_keys($options['steps']);


What about "step" and "steps" (or "current_step" and "steps" ?

To illustrate my point here: if you look at ChoiceType, it does not use "prefered_choices**_values**" or "prefered_choices**_names**"

sure we can rename this.

smnandre · 2024-12-10T23:37:21Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+ * @author Patrick Reimers <[email protected]>
+ * @author Jules Pietri <[email protected]>
+ */
+final class MultiStepType extends AbstractType


I think this is where we should describe/document what is a "step".

smnandre · 2024-12-10T23:43:02Z

src/LiveComponent/src/Storage/SessionStorage.php

+ * This class provides a session-based storage solution for managing data
+ * persistence in Symfony UX LiveComponent. It leverages the Symfony
+ * `RequestStack` to access the session and perform operations such as
+ * storing, retrieving, and removing data.
+ *
+ * Common use cases include persisting component state, such as form data
+ * or multistep workflow progress, across user interactions.


Common use cases include persisting component state, such as form data, or multistep workflow progress, across user interactions.

I'm having doubt if we should push session usage like this, as in the same time we push for stateless components, removed csrf, etc..

And i'm very hesistant to add such feature in another PR :|

I don't think these two things should be handled as one...

Will sleep on it... but already can see several alternatives:

having an internal/experimental storage (just pour the multi-step form)

using props

using existing adapters (doctrine, cache)

If it is stateless. okay we could introduce a NullStorage. But in order to be able to reload the page and having a persistent state is quite cool in my opinion.

src/LiveComponent/src/Storage/SessionStorage.php

smnandre · 2024-12-10T23:45:04Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+    /**
+     * Abstract method to be implemented by the component for custom submission logic.
+     */
+    abstract public function onSubmit();


Not sure what this mean, but onSubmit feels uncommon name.. :/

Maybe doSubmit ?

smnandre · 2024-12-10T23:45:40Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+            return;
+        }
+
+        $this->getStorage()->persist(\sprintf('%s_form_values_%s', self::prefix(), $this->currentStepName), $this->form->getData());


Suggested change

$this->getStorage()->persist(\sprintf('%s_form_values_%s', self::prefix(), $this->currentStepName), $this->form->getData());

$this->getStorage()->persist(\sprintf('%s_form_values_%s', self::prefix(), $this->currentStepName), $this->form->getData());

This feels very implementation specific to me... more on that later :)

smnandre · 2024-12-10T23:47:52Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+    #[ExposeInTemplate]
+    public function isFirst(): bool
+    {
+        return $this->currentStepName === $this->stepNames[array_key_first($this->stepNames)];


Suggested change

return $this->currentStepName === $this->stepNames[array_key_first($this->stepNames)];

return $this->currentStep === reset($this->steps);

wdyt ?

reset can return false which makes it not typesafe enough for me.

Then currentStep === .. would return false no ?

smnandre · 2024-12-10T23:48:35Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+    #[ExposeInTemplate]
+    public function isLast(): bool
+    {
+        return $this->currentStepName === $this->stepNames[array_key_last($this->stepNames)];


Suggested change

return $this->currentStepName === $this->stepNames[array_key_last($this->stepNames)];

return $this->currentStep === end($this->steps);

i would like to use the new php functions array_key_first and array_key_last.

haha the "new" :)

The "problem" (a detail, to be honest) here is that you first look for a key, then get the value indexed by that key, then compare currentStepName is identical.

But we can update this in time if necessary :)

smnandre · 2024-12-10T23:52:22Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+        $found = false;
+        $previous = null;
+
+        foreach (array_reverse($this->stepNames) as $stepName) {
+            if ($this->currentStepName === $stepName) {
+                $found = true;
+
+                continue;
+            }
+
+            if ($found) {
+                $previous = $stepName;
+
+                break;
+            }
+        }
+
+        if (null === $previous) {
+            throw new \RuntimeException('No previous forms available.');
+        }


$current = array_search($currentStep, $steps, true); if (!$current) { throw new \RuntimeException('No previous steps available.'); } $previous = $steps[$current - 1];

(or similar)

with you example the exception is thrown if no current step is available.

smnandre · 2024-12-10T23:54:22Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+        $this->getStorage()->persist(\sprintf('%s_current_step_name', self::prefix()), $this->currentStepName);
+
+        $this->form = $this->instantiateForm();
+        $this->formView = null;
+
+        $formData = $this->getStorage()->get(\sprintf(
+            '%s_form_values_%s',
+            self::prefix(),
+            $this->currentStepName,
+        ));
+
+        $this->formValues = $formData;
+        $this->form->setData($formData);


Duplicate with "next" method... should this be the main "getCurrentForm" or "getStepForm" method or something like that ?

smnandre · 2024-12-10T23:57:37Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+        $this->submitForm();
+
+        if ($this->hasValidationErrors()) {
+            return;
+        }


If !form->isValid, then a UnprocessableEntityHttpException is triggered in the componentwithformtrait, no ? So as i see it, the hasValidationErrors() check is redondant (i may have missed something)

Suggested change

$this->submitForm();

if ($this->hasValidationErrors()) {

return;

}

$this->submitForm();

not sure to be honest. i can test it.

smnandre · 2024-12-10T23:59:06Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+    #[LiveProp]
+    public ?string $currentStepName = null;


Should we make this non nullable? I don't see when a multi-step could have "no current step"

We are in a trait and we dont have a constructor or something here. which means it depends on the #[PostMount] hook. if thats not executed it is null by default. i think thats something by design we should not change.

smnandre · 2024-12-11T00:07:22Z

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

+
+        $this->stepNames = $this->formView->vars['steps_names'];
+
+        // Do not move this. The order is important.


good question :D i cann add a better comment

Co-authored-by: Simon André <[email protected]>

WedgeSama

Raw thought:

IMO, this feature can have its place in Form component, it will be useful for people/project that not using ux yet and will ease transitioning to ux.

And that way StorageInterface make sense in the Form component.

WedgeSama · 2024-12-11T08:13:51Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+
+    public function buildForm(FormBuilderInterface $builder, array $options): void
+    {
+        $options['steps'][$options['current_step_name']]($builder);


Allowing to use FormType as step can be good too. What do you think?

Maybe with something like that (haven't tested it):

Suggested change

$options['steps'][$options['current_step_name']]($builder);

$step = $options['steps'][$options['current_step_name']];

if (is_callable()) {

$step($builder);

} elseif (is_string($step) && is_a($step, FormTypeInterface::class)) {

$builder->add('step', $step, [

'inherit_data' => true,

]);

}

yes i was thinking about the same. so callback or class string of FormTypeInterface.

WedgeSama · 2024-12-11T08:14:50Z

src/LiveComponent/src/Form/Type/MultiStepType.php

+
+    public function buildForm(FormBuilderInterface $builder, array $options): void
+    {
+        $options['steps'][$options['current_step_name']]($builder);


Suggested change

$options['steps'][$options['current_step_name']]($builder);

$options['steps'][$options['current_step_name']]($builder, $options);

IMO, passing $options to keep consistent with buildForm method can be good.

sure we can do that but my question is. Why would it make sense to pass the options of the "parent" form StepType to the children? you got an example or use case where it might be useful?

It is more to be consistent with how work the buildForm method, where you have access to options.

In your PR, you cannot set your form options yet, so there is no direct example. instantiateForm method pass an empty $options (except the current_step_name) to FormFactory::create.

You may want to create step form that is configurable, either from:

your live component (not yet possible)

using FormTypeExtension from Form component

Is it clearer that way?

smnandre · 2024-12-13T00:54:43Z

My overall reaction here would be : i kinda feel 80% of this PR should be in ... the symfony/form component.

Both the "steps" logic and the "storage" logic are not related with Symfony UX and could be used without it.
... and would be very usefull seen the overall demand for it (in live component but in general too)

I'd even go to say LiveComponent could only provide a storage (in the browser DOM, via a LiveProp) for this feature.

chalasr · 2024-12-15T17:51:17Z

I tend to agree that part of the added logic could belong to symfony/form instead. Curious to know @HeahDude thoughts on this

Enhancement: Introduce MultiStep LiveComponent

0d280f9

carsonbot added Feature New Feature Status: Needs Review Needs to be reviewed labels Dec 7, 2024

silasjoisten marked this pull request as draft December 7, 2024 21:23

silasjoisten added 2 commits December 7, 2024 22:26

Fix

20ef568

Fix

6fb25c2

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/Storage/StorageInterface.php Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/Storage/StorageInterface.php Outdated Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/Form/Type/MultiStepType.php Show resolved Hide resolved

OskarStark reviewed Dec 7, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Show resolved Hide resolved

silasjoisten added 3 commits December 8, 2024 10:05

Fix

59f13dc

Require String component

c886e65

Fix

06df934

silasjoisten changed the title ~~Adds MultiStep Form Feature to Symfony UX LiveComponent~~ [LiveComponent] Adds MultiStep Form Feature Dec 8, 2024

Adds test for FormType

3c43ca5

smnandre reviewed Dec 10, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

smnandre reviewed Dec 10, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

smnandre reviewed Dec 10, 2024

View reviewed changes

src/LiveComponent/src/ComponentWithMultiStepFormTrait.php Outdated Show resolved Hide resolved

smnandre reviewed Dec 10, 2024

View reviewed changes

src/LiveComponent/src/Form/Type/MultiStepType.php Outdated Show resolved Hide resolved

smnandre reviewed Dec 10, 2024

View reviewed changes

src/LiveComponent/src/Storage/SessionStorage.php Outdated Show resolved Hide resolved

smnandre reviewed Dec 10, 2024

View reviewed changes

smnandre reviewed Dec 11, 2024

View reviewed changes

silasjoisten and others added 5 commits December 11, 2024 08:00

Update src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

a3a3514

Co-authored-by: Simon André <[email protected]>

Update src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

d2e0660

Co-authored-by: Simon André <[email protected]>

Update src/LiveComponent/src/ComponentWithMultiStepFormTrait.php

b2ea6ed

Co-authored-by: Simon André <[email protected]>

Update src/LiveComponent/src/Storage/SessionStorage.php

a67443f

Co-authored-by: Simon André <[email protected]>

Update src/LiveComponent/src/Form/Type/MultiStepType.php

4c6a065

Co-authored-by: Simon André <[email protected]>

WedgeSama reviewed Dec 11, 2024

View reviewed changes

-    }
+    }
+    public function getBlockPrefix(): string
+    {
+        return 'multistep';
+    }

		$view->vars['current_step_name'] = $options['current_step_name'];
		$view->vars['steps_names'] = array_keys($options['steps']);

	$this->getStorage()->persist(\sprintf('%s_form_values_%s', self::prefix(), $this->currentStepName), $this->form->getData());
	$this->getStorage()->persist(\sprintf('%s_form_values_%s', self::prefix(), $this->currentStepName), $this->form->getData());

	return $this->currentStepName === $this->stepNames[array_key_first($this->stepNames)];
	return $this->currentStep === reset($this->steps);

	return $this->currentStepName === $this->stepNames[array_key_last($this->stepNames)];
	return $this->currentStep === end($this->steps);


		$this->stepNames = $this->formView->vars['steps_names'];

		// Do not move this. The order is important.

-        $options['steps'][$options['current_step_name']]($builder);
+        $step = $options['steps'][$options['current_step_name']];
+        if (is_callable()) {
+            $step($builder);
+        } elseif (is_string($step) && is_a($step, FormTypeInterface::class)) {
+            $builder->add('step', $step, [
+                'inherit_data' => true,
+            ]);
+        }

	$options['steps'][$options['current_step_name']]($builder);
	$options['steps'][$options['current_step_name']]($builder, $options);

[LiveComponent] Adds MultiStep Form Feature #2433

Are you sure you want to change the base?

[LiveComponent] Adds MultiStep Form Feature #2433

Conversation

silasjoisten commented Dec 7, 2024 • edited Loading

seb-jean commented Dec 7, 2024

silasjoisten commented Dec 7, 2024

seb-jean commented Dec 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WebMamba commented Dec 8, 2024

silasjoisten commented Dec 8, 2024

smnandre commented Dec 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

silasjoisten Dec 11, 2024 • edited by OskarStark Loading

Choose a reason for hiding this comment

WedgeSama left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smnandre commented Dec 13, 2024

chalasr commented Dec 15, 2024

silasjoisten commented Dec 7, 2024 •

edited

Loading

silasjoisten Dec 11, 2024 •

edited by OskarStark

Loading