Undocumented change in set_enabled(...) behavior

[thetableman]

Question

Following a brief hiatus on a project using NiceGUI I started updating code from using 1.4.15 to 2.8.1. During this process I found that the set_enabled(...) method no longer behaved the same way.

Consider the following example:

from nicegui import ui

def handle_click(state, value):
    if not state:
        select.set_enabled(False)

    select.set_value(value)

    if not state:
        select.set_enabled(True)

select = ui.select(options=[1, 2, 3], value=1, on_change=lambda v: ui.notify(v))

ui.button('Select Enabled', on_click=lambda: handle_click(True, 2))
ui.button('Select Disabled', on_click=lambda: handle_click(False, 3))

ui.run()

When run using 1.4.15 the ui.notify is not triggered when select.set_enabled(False) is applied prior to its value being updated, when using 2.8.1 the ui.notify is triggered regardless of whether the element is disabled or not.

I couldn't identify anything in the documentation to pinpoint when this may have occurred or if it was an intended change.

[falkoschindler]

Hi @thetableman, welcome back! 😀

I'm struggling to understand the exact problem. Can you, please, describe it step-by-step:

1. What are you doing to reproduce the problem?
2. What are you expecting to happen?
3. What happens instead?

Can we reproduce the problem with the following simplified code snippet?

select = ui.select(options=[1, 2, 3], value=1, on_change=ui.notify)

ui.button('Increment', on_click=lambda: select.set_value(select.value + 1))
ui.button('Decrement', on_click=lambda: select.set_value(select.value - 1))

ui.button('Enable', on_click=lambda: select.set_enabled(True))
ui.button('Disable', on_click=lambda: select.set_enabled(False))

Any maybe you can narrow down the NiceGUI version where the behavior changes.

Last but not least: Do you think the new behavior is worse than the old one? Or do you primarily ask out of curiosity?

[thetableman]

Thanks for the response, I'll try to clarify.

1. To reproduce the issue I ran the provided example using NiceGUI 2.8.1 and 1.4.15
2. When the ui.select is disabled it was expected that the on_change callback would NOT be triggered
3. In 2.8.1 the callback IS triggered.

Yes, your code suggestion also replicated the difference in behavior between 1.4.15 and 2.8.1

It looks like the change was made in release 1.4.36.

Yes, I think this behavior is worse though do recognize the counter arguments provided in #3522 and #3524.

[falkoschindler]

This might be related: #3733, #3736.

[thetableman]

I think I've found the change - related to #3522, #3524

[thetableman]

The rationale here is that there may be a need to change the value of an element without triggering the element's on_change.

Consider the following example, changing the date triggers its related callback but also that of the select.

from datetime import datetime
from nicegui import ui

def select_change():
    ui_date.set_value(f'2025-01-{ui_select.value}')
    common_change()
    ui.notify('select triggered')

def date_change():
    ui_select.set_value(datetime.strptime(ui_date.value, '%Y-%m-%d').day)
    common_change()
    ui.notify('date triggered')

def common_change():
    """Some process that calls data based on a date change"""

ui_date = ui.date(value='2025-01-15', on_change=date_change)
ui_select = ui.select(options=list(range(1,32)), value=15, on_change=select_change)

ui.run()

Previously, to avoid this issue, I could simply apply .set_enabled(False) and prevent related elements from triggering thus avoiding a double-call to collect data. In summary, only one element needs to trigger the request for data however both need to represent the same information.

Additionally, if you think about a ui.button, the terminology for the callback is on_click, which implies the button needs to be activated by a user from the UI. A button can't be clicked programmatically (unless automating for the purposes of testing). Therefore, I expect an on_change to follow the same logic, a callback initiated by a user from UI.

I don't disagree with the need to allow an element to trigger its callback even when disabled (or invisible) as other users have noted, however, an ability to temporarily disable the callback is also useful. Perhaps a disable_on_change property can be added to ValueElement?

[falkoschindler]

Ok, I see. The "click" event is blocked by disabling the element, but the "change" event isn't. But I think the "change" event needs to always trigger, no matter how the value changes.

In your scenario you're disabling elements to avoid database updates being called multiple times. I don't fully understand how this works, but I don't think introducing yet another parameter like disable_on_change is the best way forward. Instead you can simply check the enabled state in your handler:

def select_change(e: events.ValueChangeEventArguments):
    if not e.sender.enabled:
        return
    ...

Or you introduce a dedicated flag in your user code instead of using the enabled attribute.

[thetableman]

Thanks, @falkoschindler.
Yes, there are of course several different workarounds but I do disagree with the statement:

But I think the "change" event needs to always trigger, no matter how the value changes.

This suggests that there are, in your view, no scenarios where the value of a element needs to change without triggering a script and this just simply isn't the case. There is a definite need to be able to simply set a value without the need to trigger an associated script - sometimes you just want a ui.select to display a different value or preload with other options without triggering something related.

I actually struggle with the opposite view noted in #3522. If you changed the value of a ui.select programmatically and it didn't trigger the callback (as was the behavior in version 1.4.15) then you can easily call the callback function directly straight afterwards - that's actually a simpler process than the workarounds to the current behavoir.

I asked ChatGPT out of interest and it offered this advice:

Whether a change to a list of options in a web development framework should always trigger a function depends on the use case, the specific context, and the desired user experience. Here's a breakdown of considerations:
When It Should Trigger a Function

Dynamic Updates
If the list of options affects other parts of the UI (e.g., filtering, sorting, or populating dependent dropdowns), triggering a function is essential for maintaining the application state and responsiveness.

Validation or Processing
If changes to the options require validation or any business logic (e.g., ensuring a user selects at least one option), triggering a function ensures the app behaves correctly.

Real-Time Features
In cases where changes need to be reflected immediately (e.g., live search or updates to a chart), triggering a function is necessary for seamless functionality.

State Management
In frameworks like React or Vue, changes to a list often update the component's state, which may trigger re-renders or computations. This is a core part of reactive programming.

When It Might Not Be Necessary

Static Data
If the list is static or the change is purely local (e.g., UI decoration, no downstream dependencies), it might not need to trigger a function.

Deferred Processing
For performance reasons, you may want to batch updates or process them later (e.g., debounce user input or wait for a "submit" button click).

One-Time Changes
If the change is a one-off setup (e.g., initializing a dropdown list), it might not require additional processing beyond rendering.

Best Practices

Avoid Over-Triggering: If the function is computationally expensive or updates frequently, optimize using techniques like debouncing or throttling.

Leverage Framework Features: Use the framework's reactive capabilities. For instance, in React, changes to a state variable could indirectly trigger effects via useEffect, avoiding manual function calls.

Test Dependencies: Ensure triggering a function aligns with dependencies in your application logic to avoid unnecessary updates or bugs.

In summary, changes to a list of options should trigger a function if they have downstream effects or need processing to maintain application behavior. Otherwise, avoid overcomplicating with unnecessary triggers.

Based on this summary of scenarios I think my issue probably falls under 'Deferred Processing' - I need options to update but want to control at what point they trigger.

[falkoschindler]

This suggests that there are, in your view, no scenarios where the value of a element needs to change without triggering a script and this just simply isn't the case.

That's not what I meant. But the UI element in itself should be consistent. So if its value changes, the "value changed" event should be triggered. That doesn't mean that your code needs to run no matter what. You can exit early depending on any condition you want, as suggested above.

[thetableman]

I respectfully disagree with this outcome, particularly as the change in PR #3524 altered default behavior without providing a clean API supported alternative, but appreciate your time and consideration as always.