Patch and warn late event registrations

[evnchn]

Motivation

Reading #4154 and #4828 again, I come to the following conclusion:

1. Late event registrations are fundamentally misaligned with Vue's design. (reference: Events such as keydown and keyup are not triggered by an ui.input when not assigned directly upon creation #4154 (comment))
2. Therefore, we do not need to aim for perfect behaviour if late event registrations do occur (so Force Vue re-render on late event registration #4828 (comment) should not matter)
3. Rather, "best effort patch" and "warning to the user" is the way to go.

Hence this PR.

Implementation

Code is extremely similar to #4828

Before we process the list of elements, we do a check to see if there are any new events sent in by the server.

• If there is, then:
  • We remove that element from Vue's this.elements
  • We mark that we need to await this.$nextTick();
  • We proceed to await this.$nextTick(); to force the Vue to render without that element
    • Do it ONCE only, for performance
  • In such a way, when we process the list of elements as usual, Vue will be like
    • "hey I haven't seen this element before, let me render it"
• If there is none, then fine, do nothing.

But on top, I added warnings both in Python-land and JS-land.

Progress

• I chose a meaningful title that completes the sentence: "If applied, this PR will..."
• The implementation is complete.
• Pytests have been added.
• Documentation is not necessary (warning message self-explanatory).

Final notes

How I read it, #4828 was closed because:

• Accidental closure
• Significant merge conflict due to NiceGUI 3.0
• Focus on perfect behaviour (no focus drops)

Both of which should no longer be blockers, given the new code and new positioning on the issue.

So hopefully this gets a pass. Thanks!

[falkoschindler]

Thanks for the pull request, @evnchn! I finally looked into it:

1. Input elements still loose focus. But I guess that's better than no event registration at all.

2. There's an inconsistency between Python and JavaScript: The Python warning triggers for any listener change (add/remove, same or different type), while JS only re-renders for new event types. Here is an example where this fails to register the second event handler:

   i = ui.input().on('keydown', lambda e: print(e))
   ui.timer(1.0, lambda: i.on('keydown', ui.notify), once=True)

3. Maybe it would be a good opportunity to change the "too_long_message" event to a more generic "warning" event. Then we could let the client create the warning for all and avoid re-implementing the detection in Python, probably fixing point 2.

4. Overall it's quite some code for an imperfect solution. But maybe thats the best we can do. With point 3 this PR will mainly take place in nicegui.js. And it's not the fault of this PR that nicegui.js is borderline unreadable with its almost 500 poorly structured lines of code. 😉

[evnchn]

1. yes
2. 6a1abb6
3. 5d65b75
4. 61c7cfa

[evnchn]

Actually do we really need such a big popup for re-rendering the element. Maybe just invoking the Quasar loading bar at the top of the page for a split second is enough to indicate some loading is happening.

Regardless I think both is fine because either way late-registrations are not recommended.

[falkoschindler]

I didn't expect you to change any popups. I was just thinking about merging multiple errors/warnings into a single message topic. We probably shouldn't implement so many popups, especially for technical details like an event registration. Logging the warning should suffice for the developer to notice.

Oh and tests are failing right now.

[evnchn]

Should be good:

• No more popup. It just console.warns. Should be enough to get an attentive person's attention.
• Fix the tests and make it stricter in the meantime.

[falkoschindler]

I just introduced a "log" message as an easy way to log warnings and errors both in JavaScript and Python. This replaces the hacky "too_long_message" message. The test is green. Here is my code for experimentation:

# experiment with large payloads
ui.textarea(value='x' * (1_000_000 - 242), on_change=lambda e: ui.notify(f'{len(e.value)} characters'))

# experiment with late event registration
name = ui.input()
name.on('keydown.a', ui.notify)
ui.timer(1.0, lambda: name.on('keydown.b', ui.notify), once=True)

Do you agree, @evnchn?

[evnchn]

While it works for the most part, this breaks polling transport.

Try it with core.app.config.socket_io_js_transports = ['polling']