configure() called before boot()

[betullam]

What happened?

I upgraded from version 2.15.0 (on Laravel 10/Livewire 2) to version 3.4.20 (on Laravel 11/Livewire 3). In my table components, I set some properties in the boot() method that I want to reuse in configure().

With version 2.15.0, this was no problem. The order of the method calls were:

1. boot() (set properties here)
2. configure() (use properties here)

With version 3.4.20, setting properties in boot() throws the error Typed property App\Livewire\Tables\MyTable::$propertyName must not be accessed before initialization. I checked the order of the method calls and saw that it is now like this:

1. configure() (should use properties here, but they are not set yet because boot() is not called yet)
2. boot()
3. configure()

Because configure() is called before boot(), it can't use the property that is set in boot(). Furhtermore, configure() is called a second time after boot(). I suppose the first call to configure() should not be executed.

How to reproduce the bug

Here is a code to reproduce the issue:

<?php

namespace App\Livewire\Tables;

use App\Models\User;
use Rappasoft\LaravelLivewireTables\Views\Column;
use Rappasoft\LaravelLivewireTables\DataTableComponent;

class MyTable extends DataTableComponent
{
    protected $model = User::class;
    public string $primaryIdField;

    public function boot(): void
    {
        $this->primaryIdField = 'id';
    }

    public function configure(): void
    {
        $this->setPrimaryKey($this->primaryIdField);
    }

    public function columns(): array
    {
        return [
            Column::make('ID', 'id')
                ->sortable(),
            Column::make('Name')
                ->sortable(),
        ];
    }

}

Package Version

3.4.20

PHP Version

8.2.x

Laravel Version

11.22.0

Alpine Version

3.13.3

Theme

Tailwind 3.x

Notes

No response

Error Message

No response

[lrljoe]

I'm not understanding why you're setting that in boot()

Your example:

    public string $primaryIdField;

    public function boot(): void
    {
        $this->primaryIdField = 'id';
    }

So given that "primaryIdField" will NEVER BE anything other than "id" in your example (as it'll revert to "id" on every lifecycle), just set it to that?

    public string $primaryIdField = 'id';

The package follows the conventions for Livewire in so much that there are some checks for query string which depend on configure() being executed.

Loading things like static variables in as public will decrease your performance (this applies to ALL Livewire components), and should only be done if you either want to persist something that changes in the backend, or something that is "wired" in the frontend.

[lrljoe]

Converted from bug, as is not actually a bug.

There are numerous upgrade guides etc that explain the behaviour of lifecycle differences between LIVEWIRE 2, and LIVEWIRE 3.

The Tables package was updated to use the Livewire 3 approach, which is why it requires Livewire 3.

[betullam]

The code I posted here is just an example to illustrate the issue and for the sake of conciseness. My production code is more complex and is not setting the primary ID field - again: this was just for giving a short example. In fact I have a base table class that is extended in many child table classes where I set some properties of the base class. Some of the values for these properties are coming from config files. The properties are then used in the boot() method of the base class for further use (e. g. to calculate the filters for each child table).

I just wanted to be sure that configure() should really be executed before boot(), because in version 2 this was not the case, so I thought this might be a bug.

After some googling I couldn't really find upgrade guides that explain the differences in lifecycle hooks between Livewire v2 and v3 that are related to that issue. If you could point me to some I would be happy to read them.

[lrljoe]

I'm hoping to have time this weekend to re-review where the calls are being made to ensure the lifecycle is working as it should!

[lrljoe]

So I've got to the bottom of it, and it will be fixed in the next release.

[lrljoe]

As part of the rewrite of the Query String behaviours, I've ensured that configure() is callled once.

It is called in booted(), so after boot() completes, which is the sensible place for it.

PR is #2018

Hope to merge it in tomorrow (Sunday) sometime.

[betullam]

Thank you very much for your effort!

[lrljoe]

This will be in the next release, but due to the number of different PRs being merged in, I do need to add a few tests, and a couple of documents to it before I release it. Expect it this weekend.

[lrljoe]

This should be fixed in the latest release. Let me know if it isn't please!