search

jupyter / dashboards_server

[RETIRED] Server that runs and renders Jupyter notebooks as interactive dashboards
Other
181 stars 48 forks source link

Include cell metadata for widgets that use it #294

Open dalogsdon opened 7 years ago

dalogsdon commented 7 years ago

Some widgets may use notebook cell metadata.

Currently the declarativewidgets_explorer (https://github.com/jupyter-incubator/declarativewidgets_explorer) saves its state in cell metadata, and the client-side JS loads available state when the explorer widget is created.

A dashboard server page doesn't include cell metadata. Is this something that can be added? The declarativewidgets_explorer is much less useful without the ability to load saved state.

jhpedemonte commented 7 years ago

This is somewhat complex, I think. If dashboards server is meant to serve a dashboard to only a single person, then this is doable (assuming updating the store notebook file). However, if multiple people can access the same page, then it falls apart -- everyone would just see the state of the last person to load/use the explorer.

I think the idea of persistence is different in the notebook vs dashboards. In notebook, you are preparing a file that can then be shared, so makes sense to update cell metadata. The dashboard, meanwhile, is more of a read-only version of that notebook. Persistence (if it makes sense in the dashboard scenario), must be handled differently.

Some options:

  1. Cookies - This is per browser, which is a decent approximation of per user.
  2. External storage mechanism - Like a database, etc. Doesn't really make sense for the Explorer.

This brings up another issue: how can code determine that it is running on the dashboards server (see #293, for example).

dalogsdon commented 7 years ago

The code is in the jupyter-persist-behavior which is part of declarativewidgets. This is client-side JS.

I would say that the persist behavior could check for dashboards to enable/disable or to select the persistence method.

We could start with enable/disable and later add save in cookie if we identify a use case. Either way we would need to set the cell metadata in the dashboard page.

parente commented 7 years ago

What state is being persisted? If it's the desired state of the explorer widget, then it really is shared across users as the initial state, right?

We currently don't have a way to differentiate code from cells being run by the dashboards server. We could specify an env var (JUPYTER_DASHBOARDS) that could then be checked by running code.

Is the proposal to put this in the kernel environment via the kernel gateway? If so, there's already a way for a client (dashboard server) to pass env vars to set on kernel launch as part of the API request.

dalogsdon commented 7 years ago

This is all client-side code, so I'm not sure an env var will be helpful.

If it's the desired state of the explorer widget, then it really is shared across users as the initial state, right?

yes

parente commented 7 years ago

This is all client-side code, so I'm not sure an env var will be helpful.

OK.

If it's the desired state of the explorer widget, then it really is shared across users as the initial state, right?

So really we're talking about how can / should the widget implementation be configured with that initial state when it first appears in the dashboard. We don't need to worry about persisting any state back per-user, per-session, per-kernel, or anything like that.

dalogsdon commented 7 years ago

So really we're talking about how can / should the widget implementation be configured with that initial state when it first appears in the dashboard.

Yes. The simplest approach is to include cell metadata in the page so that the widget loads the data in the same way (using $(this).parents('.cell').data('cell')). We could modify the persist behavior to save the metadata in a "widgets" structure similar to what we did in dashboards for jupyter extension metadata, and then only add in the widget metadata to the dashboard server page.

@jhpedemonte brought up the point that modifying the explorer would overwrite the metadata, but this won't affect other users since the dashboard server page doesn't make changes to the notebook file.

If desired we can have the persist behavior detect a deployed dashboard and save locally in the browser (e.g. in a cookie) if a user modifies the explorer, but this would likely be a future work that requires its own discussion.