Loading spinner on UI does not go away if app does not respond

[mtanco]

Q SDK Version, OS
Wave 0.10.0
Mac OSX

Actual behavior
The @app function must do something to the site for the automatic loading screen to go away

Expected behavior
Loading to only appear when main thread is blocked

Steps To Reproduce
https://github.com/h2oai/sales-engineering/blob/master/mtanco/wave/apps/client-data/app.py

The button is an example where I have not yet coded it's functionality, I would expect that when I click it nothing happens, but we get stuck in loading.
The Menu -> Home is an example where I have "changed" the site so we don't get stuck in loading:

    elif q.args.home:
        q.page['no_page'].items = []
        await q.page.save()

[mturoci]

Debugged @mtanco's code and it's fine, no long-running jobs that could block main thread. The problem is that when there are no changes to the ui on event loop tick, the server does not respond and UI thinks it is blocked. See here. We should probably always send something back even though it's empty. wdyt @lo5

[mturoci]

Note: Another change required for this to work on UI side is moving this to top of the function.

[lo5]

This is working as designed. The spinner and mask were added to address #17. It's not an indication that the server is blocked, but an indication that a request has been dispatched.

In @mtanco's case, the server does not respond, so I'd say this is not a real use case.

[mtanco]

If I had a bean counter app that counted beans but didn't display the results it wouldn't work because I wouldn't want to update the screen. I know that's trivial, but couldn't there be some app where when you click a button or something you don't want any change to the UI?

[mturoci]

my 2 cents: I understand both sides and it probably does not make sense to not update UI after user interaction, but there can be some edge cases as @mtanco is suggesting.

Main reason I think we should send empty response even for when no ui change happened is simply better dev experience, people have already quite tough time to get their head around Wave, so I would make their life easier by not putting another, not so obvious, problem to them. @lo5 is there any reason for not sending the empty response engineering-wise?

[lo5]

@mturoci - no technical reason - we'll have to implement dirty-tracking on the Page in Python-land, so icky. Not sure if it's worth the effort.

If you think about it, this is equivalent to authoring a request handler in a non-Wave app, but not providing a response, which begs the question - why have the handler there in the first place?

I can understand that a first-time user might be puzzled, but the same applies to a first time user of Django or Flask - if you don't respond to the browser, you don't see a response in the browser.

Look at it this way -

Hiding the spinner (via an empty response) might be even worse for both first time users and advanced users - you will be unable to distinguish between (A) my app responded, and the UI did not change because the command produced the same result as before, and (B) my app did not respond because some if-elif somewhere has a bug in conditional logic.

At least with Peto's implementation, if the spinner does not go away, you know it's [B] without having to reach for a debugger.

So we need a strong reason and examples of apps where you'd want a button click or some command to not respond to the user.

[mturoci]

I can understand that a first-time user might be puzzled, but the same applies to a first time user of Django or Flask - if you don't respond to the browser, you don't see a response in the browser.

Makes sense.

[mtanco]

I am comfortable closing this after this discussion - but I don't think I'm the only person that's going to be confused, think something is broken, etc. (At least one other people has asked on slack). So, yes this is working as expected but how can we make sure that people know this? Note in docs? Post in discourse? or just wait until the next person asks and explain it

[lo5]

We can keep this issue open. If it bothers others, we'll think about it again. As of today I think addressing it would result in worse UX than not addressing it.