@on() Handlers behave differently after upgrade from WAVE 0.24.2 to 0.25.2

[Nayananga]

In wave 0.24.2

Screen.Recording.2023-03-23.at.11.34.42.mov

in wave 0.25.2

Screen.Recording.2023-03-23.at.11.33.14.mov

sample code:

from h2o_wave import main, app, Q, ui, on, handle_on


@on()
async def button_click(q: Q):
    q.page['meta'] = ui.meta_card(box='', notification_bar=ui.notification_bar(
        text='you clicked button',
        type='success',
        position=ui.NotificationBarPosition.TOP_CENTER,
    ))

    await q.page.save()


@on("#hash_route")
async def dropdown_handle(q: Q):
    q.page['meta'] = ui.meta_card(box='', notification_bar=ui.notification_bar(
        text='you clicked hash route',
        type='success',
        position=ui.NotificationBarPosition.BOTTOM_CENTER,
    ))
    await q.page.save()


@app('/demo')
async def serve(q: Q):
    await handle_on(q)
    q.page['meta'] = ui.form_card(box='1 1 2 2', items=[
        ui.button(name='button_click', label='Button Click'),
        ui.button(name='#hash_route', label='Change Hash route'),
    ])

    await q.page.save()

This behavior heavily affects apps that already use @on() handlers, they need to be completely revamped and tested. Any thoughts?

[mturoci]

The current handle_on mechanism is about to be deprecated in (hopefully) next version as it has a lot of design flaws, on of which being dependant on the order of q.args/q.events. I recommend using either some custom solution or good old if else statements until then.

Note that your app should never depend on the order of q.args/q.events as it's not guaranteed. Instead, you should handle them all regardless of the order they come - handle them as batches rather than individuals.

[dulajra]

@mturoci Then are you saying what is mentioned in the docs are also invalid?

[dulajra]

note that handle_on is doing the very same under the hood as well

If that is the case why are you planning to remove handle_on from the framework and recommend using if-else for the developers? You can keep hande_on and let the developer to decide what to use for their use case.

[mturoci]

Then are you saying what is mentioned in the docs are also invalid?

Why? All it says is that if it seems repetitious to you, you can use handle_on. It doesn't say it's the preferred way for large apps. We explicitly say what is our recommendation regarding code structure in https://wave.h2o.ai/docs/routing/#organizing-code.

If that is the case why are you planning to remove handle_on from the framework and recommend using if-else for the developers?

Please read my comments thoroughly. I said we are going to replace handle_on with a newer, better version. Removal is not mentioned at all.

You can keep hande_on and let the developer to decide what to use for their use case.

Again, read what I wrote above. This is what is happening.

[dulajra]

The amount of interactions doesn't matter at all, what matters is cyclomatic complexity of the code which makes it hard to maintain.

That's what I meant also. The amount of interactions is a direct contribution to increase the cyclomatic complexity of the code if we are going to use if-else for each event. And there is another problem contributing to the same factor because of the design of wave. If we consider any other framework like React or Angular then we can register listeners for events. Each listener is responsible for taking care of that particular event. But in Wave, there is no way to decide the exact event which triggered that serve cycle. We need to do so many state comparisons manually to decide which event caused the serve cycle to trigger. These state checks will also contribute = to the cyclomatic complexity.

[mturoci]

The amount of interactions is a direct contribution to increase the cyclomatic complexity of the code if we are going to use if-else for each event

This is not true. This would be only problematic if you have deep if else nesting => spaghetti code. Having a single level, flat if else statements is a no-brainer + gives you flexibility to build your own mechanism around that (you can even get rid of if else statements completely and split them into dedicated functions, bring your own event processing mechanism tailored to exactly to your needs) + other benefits mentioned above.

If we consider any other framework like React or Angular then we can register listeners for events.

I suggest digging deeper than just syntax level. Then you will learn Wave behaves exactly like these 2 (or JS in general) frameworks. How do you think events from React get into your defined handler? The only difference is that Wave provides finer control over triggering handlers which is better for every experienced developer.

[mtanco]

Order of q.args is never guaranteed, so in general this is “risky” practice to assume that the event you want will be first in line. In wave 0.25.2 there was a change that moved # values to the front of the q.args list. Because of #769, the # value is in q.args even if it has not changed. For this reason, the # on function is getting called instead of the button that the user is clicking on.

The location of # in q.args can be reverted to pre-0.25.2, but this does not change that q.args order cannot be guaranteed. This will be applied to 0.25.3 which can be cut early week of 05/08.

Handle_on has a series of problems that developers have ran into, but are working around and using today in their apps. To improve this functionality without breaking existing apps, a new method (something like "handle_change") will be created in the coming weeks. After developers have had sufficient time to move over, the handle_on functionality will be depreciated and removed.