fix(repeater): bubble afterStateUpdated to parents

[Domianidze]

Description

This PR addresses an issue where afterStateUpdated callbacks on parent components were not being triggered after running repeater-related actions such as add, delete, reorder, etc.

In these cases, the component would call afterStateUpdated on itself at the end of the action, but unlike normal state updates, the update did not bubble up to its parent components. This meant any logic relying on afterStateUpdated at the parent level would silently fail to run.

To fix this, a new helper was introduced that first checks if the component is live, and then recursively walks up the component tree, calling afterStateUpdated on each parent. This mirrors the behavior of actual state updates, ensuring that all necessary callbacks are triggered.

This approach has worked well in our testing and reflects the expected behavior of how state updates should propagate. Let me know if there’s a more appropriate way to handle this logic, or if there are any edge cases we might’ve missed.

Visual changes

No visual changes.

Functional changes

• Code style has been fixed by running the composer cs command.
• Changes have been tested to not break existing functionality.
• Documentation is up-to-date.

[danharrin]

When you mention parent components, can you provide an example of some code that is currently broken? I'm not even sure that running the hook on parents is desired behaviour but I would like to hear what you are using this for first?

[Domianidze]

For example, in our case we have a Section component that contains various fields, some of which are Repeaters. On the side, we have a live preview that should update anytime any field changes. On the section we have an afterStateUpdated function set that refreshes the preview.

Example:

Section::make()
    ->schema([
        TextInput::make('heading'),
        Repeater::make('blocks')
            ->schema([
                TextInput::make('image'),
            ]),
    ])
    ->afterStateUpdated(fn () => $this->updatePreview())
    ->live(),

Normally, if a user edits the heading field, the afterStateUpdated hook runs, and the preview refreshes.

Problem:

If a user adds, deletes, reorders or does any of the repeater actions inside the blocks Repeater, the Repeater would call its own afterStateUpdated, but the Section’s afterStateUpdated doesn’t get triggered. As a result, the preview doesn’t update.

This is why we made the change to bubble afterStateUpdated up through the parent components to match how normal state updates behave.

[danharrin]

Does the section have a statePath() defined or anything in your example?

[Domianidze]

Only thing relevant it has is live(), which is what causes the normal field changes to bubble up the afterStateUpdated to the Section. That’s why I’m checking if the Repeater is live before bubbling it up to mirror the normal state updates.

(Sorry, I forgot to include that in the example.)

[danharrin]

Honestly that is super weird behaviour, I never knew it did that. So I will need to look into the underlying cause and decide whether or not that is desired behaviour. Sorry, that will result in a delay to this PR.

[Domianidze]

No worries, I’ll be here to help if I can.