I have a notebook that renders a few data visualizations.
The cell width is narrow and constrains the ability to view detail in the datasets. So far, this has proven useful for prototyping, but the cell width is turning out to be a technical limitation for a production app to point others to.
Is there a way to make the default cell width a larger value, so that I can render the datasets in greater (and more usable) detail?
Short of that, how would I make the notebook code “listen” for entering Fullscreen API mode (e.g., demo’ed here: Slide / Mike Bostock / Observable) so that I could use a different function for rendering the datasets, which would take advantage of the wider viewport dimensions?
The default max width is 1152, so you could have a cell like isFullscreen = width > 1152 and render a different render function depending on that. Example:
Using Observable’s width variable is not a great solution, as every change to the viewport’s width will cause all dependent cells to reevaluate. Instead, use matchMedia, like I’ve demonstrated here:
Fullscreen can only be detected if it is requested from within the notebook - you won’t be able to react to Observable’s “view in fullscreen” option. However, fullscreen alone doesn’t guarantee a wide enough viewport, so I would instead suggest to make your layout dependant on a specific width threshold.
If you want to extend the width that is utilized within Observable’s UI for yourself, you can add the following user style (e.g. via the Stylus extension):
For a production app, I probably can’t expect users to install browser-specific extensions. But the issue with width causing cell recalculation is useful to know about, thanks!
If this is for a production setting, have you looked at embedding Observable notebooks into another website using the runtime API?
In that context, users wouldn’t see any of the Observable UI, including “View in fullscreen”. You could make your notebook content fill the full width by default. And, as @mootari said, it makes sense to base your breakpoints on the natural demands of your content.
The following notebook has turned out to be useful for what I am trying out, so far: height / Fil / Observable
I think I can live with a per-resize cost for re-rendering if the width changes, but obviously it will be easier to know if that is true once the old code is ported over and refactored.
I think once I have a production page going that works well, I can also start looking at embedding the notebook into another site.