Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP feat: progressively load the widgets while the kernel is executing #768

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

maartenbreddels
Copy link
Member

This will connect to the kernel as soon as possible, and tries to create
widget during execution. This avoids having to get all the widgets after
execution, and is an alterative to:
#766

Issues:

  • since the whole jupyter message handling is 'synchronous' it awaits
    at a top level and goes all the way down, get_model needs to be resolved
    without any new message coming from the kernel.
  • Despite making handle_comm_open not returning a promise, we still get
    a stalling of the whole message q.

Despite these issues, the loading time is significantly reduced, since
the page renders almost instantly when it succeeds (e.g. when no widgets
are missed).

This will connect to the kernel as soon as possible, and tries to create
widget during execution. This avoids having to get all the widgets after
execution, and is an alterative to;
voila-dashboards#766

Issues:
 * since the whole jupyter message handling is 'synchronous' it awaits
   at a top level and goes all the way down, get_model needs to be resolved
   without any new message coming from the kernel.
 * Despite making handle_comm_open not returning a promise, we still get
   a stalling of the whole message q.

Despite these issues, the loading time is significantly reduced, since
the page renders almost instantly when it succeeds (e.g. when no widgets
are missed).
@maartenbreddels maartenbreddels marked this pull request as draft November 19, 2020 18:16
@maartenbreddels
Copy link
Member Author

Note to self, we can do this a different way:

  • create the comms at the client, but don't create the widgets, store the msg that was send when the widget was created.
  • when an update msg gets send, the easy way would be to drop the last msg.
  • when we build the widgets, ask for the comms, and see what we missed, and only ask updates for those widgets.

@jtpio jtpio added the enhancement New feature or request label Jun 23, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants