Include cell metadata for widgets that use it

[dalogsdon]

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]

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).

• If the code is part of the JavaScript running on the page, then it can check for the existence of window.jupyter_dashboard.
• 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.

[dalogsdon]

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]

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]

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]

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]

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.