resolveUsing callback is executed every time the dependsOn callback is triggered and results in non-reactive behavior for the BooleanGroup field (and possibly other fields)

[piljac1]

• Laravel Version: 9.8.1
• Nova Version: 4.7.0
• PHP Version: 8.1.5
• Database Driver & Version: MySQL 8.0.21
• Operating System and Version: macOS Monterey 12.1
• Browser type and version: Google Chrome Version 101.0.4951.64
• Reproduction Repository: https://github.com/piljac1/nova-issue-4329

Description:

If a BooleanGroup field depends on another field and you have a resolveUsing callback that is set, the resolveUsing callback is called every time the dependsOn callback is triggered and it seems to break the dependsOn behavior (new options that are set within the dependsOn callback are not rendered).

Detailed steps to reproduce the issue on a fresh Nova installation:

Select::make('Site', 'site_id')
    ->options([
        1 => 'Site #1',
        2 => 'Site #2',
    ])
    ->displayUsingLabels()
    ->searchable()
    ->rules(['required']),

BooleanGroup::make('Test')
    ->dependsOn(
        ['site_id'],
        function (BooleanGroup $field, NovaRequest $request, FormData $formData) {
            $options = $formData->site_id
                ? ['test' => 'Test']
                : ['test2' => 'Test2'];

            // Options are set to ['test2' => 'Test2'] on page load (because no site_id is selected)
            // ...and they never change even if you select a site_id in the parent "site_id" Select field,
            // even if we can clearly see when inspecting the request response that they're returned as intended.
            $field->options($options);
        }
    )
    ->resolveUsing(function ($category, $model) {
        // Since resolveUsing is called everytime dependsOn gets triggered,
        // I had to check request()->site_id first because when creating, there's no model instance set.
        // Even if the $siteId contains the appropriate value
        // and $options are assigned properly, the mere fact that a resolveUsing callback is defined
        // seems to completely render the dependant behavior unreactive.
        $siteId = request()->site_id ?: $model->site_id;

        // In this simple reproduction example, the resolveUsing has no purpose because it replicates
        // the default behavior (always false by default), but when dynamically assigning values in a real world
        // example, the issue is the same.
        $options = $siteId
            ? ['test' => false]
            : ['test2' => false];

        return $options;
    })

Additional information:

Original issue: #4294

[crynobone]

Apparently this is still an issue even after today's release. We can see the new options in the request's response, but they never get updated.

Please be specific with what you mean about "they never get updated"? Update Description and Detail reproducing steps instead of just referring to another issue.

[piljac1]

Apparently this is still an issue even after today's release. We can see the new options in the request's response, but they never get updated.

Please be specific with what you mean about "they never get updated"? Update Description and Detail reproducing steps instead of just referring to another issue.

@crynobone I dug a bit deeper and found that the options that are correctly changed and reactive when set within the dependsOn callback if the original reproduction example (#4294) is used. However, if you add a resolveUsing callback to the mix, the reactivity is gone, no matter what you do in the resolveUsing callback. I updated the issue title and description with a reproduction example which replicates the problem. It seems like the resolveUsing callback is called every time the dependsOn callback is triggered. I don't know if that's to be expected (to me it sounds like resolveUsing should only be used on page/form load), but even if it is, it seems to break the options reactivity.

[crynobone]

I would need to see a full reproducing repository for this. Please submit one similar to https://github.com/nova-issues

[piljac1]

I would need to see a full reproducing repository for this. Please submit one similar to https://github.com/nova-issues

@crynobone Alright, I will try to spin one up because the original one is a private unreleased project. I'll let you know. Thanks!

[crynobone]

Also you need to resolve the field before applying depends on logic. This feel like change of behavior now rather than a simple bugfix.

[piljac1]

@crynobone Not sure I understand. Do you mean that it would require a lot of work on your end or that there's something I did wrong in my reproduction code? If so, can you explain please? Thanks!

[crynobone]

The current behaviour now is that you always resolve the field and then apply depends on. Changing the sequence may fix your issue but introduce risk of breaking someone else code.

It would be best to duplicate the resolveUsing code in dependsOn.

[piljac1]

@crynobone Alright, I'll try to dabble with it tomorrow, but meanwhile, here's the reproduction repo (if you wanna take a peek or try it out on your end).

https://github.com/piljac1/nova-issue-4329

[piljac1]

@crynobone Alright, so I dabbled with it and found a workaround (see my second latest commit). That being said, I still believe there's a bug with how resolveUsing interacts with the dependsOn behavior. Right now,  even if the resolveUsing callback is called beforehand when dependsOn is triggered, even if we resolve the value as intended, it prevents the dependsOn callback to dynamically change/update options.

If you log what the resolveUsing callback returns, it behaves as expected (returns a key => boolean array of the new options that will be changed by dependsOn). Then, in the dependsOn callback, if you log the new options that should replace the old ones, they're the expected ones. However, when you try to make both work together, they don't: reactivity just becomes inexistant).

The following is somewhat unrelated

Another unrelated issue that I found when debugging (I don't know if it is expected), is that $this doesn't contain a resolved resource in subsequent resolveUsing and dependsOn calls. It just contains an empty resource (empty model). So if you want to do comparisons with the values of the model you're editing, you need to query it from the database manually using the resourceId found in the route.