Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

dmytroshved's avatar

Question about model binding in Livewire 3

In Livewire 2 it was common to use this code for model binding:

public Post $post;
 
protected $rules = [
    'post.title' => 'required',
    'post.description' => 'required',
];
<input wire:model="post.title">
<input wire:model="post.description">

doc: https://livewire.laravel.com/docs/upgrading#eloquent-model-binding

But now, in Livewire 3 I wanna to get this behaviour, documentation says that I can get this behavior via a configuration item in config/livewire.php:

'legacy_model_binding' => true,

But I wanna to be with Livewire 3 standarts and I wanna ask you how should I proceed now?

my code below:

public Recipe $recipe;

public function mount(Recipe $recipe)
{
     $this->recipe = $recipe;
}

and my view:

<!-- Recipe name -->
     <div>
        <label>Recipe name</label>
         <input wire:model="recipe.name"
                    name="recipe.name"
                     type="text"
                    placeholder="Chicken Broth"
         />
        @error('recipe.name')
         <span>{{ $message }}</span>
        @enderror
    </div>

and as expected, it doesn't work in Livewire 3

ChatGPT suggests use arrays (but I don't wanna rely only on gpt):

 public $recipe_data = [];

public function mount(Recipe $recipe)
    {
        $this->recipe_data = [
            'id' => $recipe->id,
            'name' => $recipe->name,
            'description' => $recipe->description,
            'image' => $recipe->image,
        ];

    }

I would be grateful for advice

0 likes
11 replies
tisuchi's avatar

@dmytro_shved If I am not mistaken, Livewire 2 and 3 have some major changes. I suggest you check it first in the change log documentation, to grasp a good understanding of changes.

Then only go for upgrading your app, either manually or using some AI.

1 like
jj15's avatar
jj15
Best Answer
Level 10

In v3, the common way now is to extract each of the model's attributes as separate properties. To go further, you can encapsulate them into a form object.

The form object:

namespace App\Livewire\Forms;

use Livewire\Attributes\Validate;
use Livewire\Form;

class RecipeForm extends Form
{
    #[Validate(['required', '...'])]
    public string $name;

    public string $description;

    public string $image;
}

Your component:

use App\Livewire\Forms\RecipeForm;
use Livewire\Attributes\Locked;

#[Locked] // <- This tells Livewire to prevent this property from being changed client-side, for security.
public int $id;

public RecipeForm $form;

public function mount(Recipe $recipe): void
{
    $this->id = $recipe->id;
    $this->form->name = $recipe->name;
    $this->form->description = $recipe->description;
    $this->form->image = $recipe->image;
}

public function save(): void
{
    $this->form->validate();

    Recipe::findOrFail($this->id)->update($this->form->all());
}

I typed most of this from memory so there may be some errors, but it should give you the basic idea and starting point.

2 likes
dmytroshved's avatar

@jj15 I'd like to clarify one point.

After watching a Laravel Daily video tutorial about form objects, the author shared their personal opinion about using form objects in a scenario where a developer wants to reuse a form for both creation and updating.

In their opinion, if we have validation rules like unique or exists, it will cause problems, and it's better to split these two forms.

What do you think about this? Here's a link to the video with the moment when the author talks about this: https://youtu.be/uQ1gM1ZOAHU?t=334

In my component i have a unique rule for recipe name in validation


I'll need to think about this further. For now, I want to consider all the implementation methods and choose the one that suits me best.

Currently, I have these thoughts:

  • I cannot use model binding in Livewire 3.
  • I can use 'legacy_model_binding' => true, but this is a workaround and not a sustainable option.
  • Form objects are not very practical when I need to reuse the form for creating and updating a recipe in one component.
  • For now, the most obvious and simple option is to create two forms, one for creating and one for editing a recipe. Each form will use form objects to reduce the amount of code.
jj15's avatar

@Dmytro_Shved If you need to split them into two form objects, that's fine. Aside from that, is it necessary to require that each recipe have a name that's unique? Multiple users could have their own recipe for the same dish.

1 like
dmytroshved's avatar

@jj15 to be honest, i saw the idea of a unique recipe name on another site, if a user wants to create a recipe with the same name, he will have to rephrase it a little, i haven't thought about changing this logic yet

1 like
dmytroshved's avatar

@jj15 I will definitely implement recipe filtering, and I plan to enable searching for recipes by name, so name uniqueness is likely necessary

dmytroshved's avatar

@jj15 To clarify the question, I also want to mention that my wizard form has 3 steps, on steps 2 and 3, I have implemented dynamic form fields for ingredients and recipe instructions.

The complexity is further increased by the fact that ingredients and recipes are linked using a pivot table.

Furthermore, the code includes logic that creates a new ingredient in the database if it doesn't already exist.

If needed, I can provide the code, but it's quite extensive. I'm currently considering whether to reuse this form to both create and update records.

dmytroshved's avatar

@jj15 Yes, thanks for the advice.

I just finished moving all the logic to form objects yesterday and now I can work on it further.

Please or to participate in this conversation.