I’ve been referring to these as “inspector cells”. All cells are defined by code, and this code is hidden by default; it’s only shown if the cell is pinned or focused. An inspector cell is any cell that doesn’t return DOM. When a cell returns some non-DOM value such as a number, string, object or function, this is displayed by Observable’s built-in inspector (much like a browser’s developer tools).
There’s no way to hide a cell entirely, and that’s mostly deliberate: we want the code to be accessible to readers so they can read it, learn from it, and even tinker with it. We are view-source at heart.
It is often the case, however, that a cell can be useful for implementation without fitting easily into the narrative flow. What I do for these cells is put them at the end under an Appendix h2 header. For example:
A more extreme approach would be to hide the inspector entirely via CSS:
html`<style>.O--inspect { visibility: hidden; }</style>`
But, note that the cell names would still be visible in the left margin, so that might be a little weird.
Another approach is to use viewof to override the default inspector and instead show arbitrary DOM. Kelley van Evert shows how (see the def cell for implementation):
Perhaps the cleanest approach is to use imports. If you break your notebook into two notebooks—one explanatory, mostly Markdown and narrative; the other implementing the chart (possibly exploratory)—then you can import the chart into your explanatory notebook without needing to also show those implementation cells. The import statement would be visible, however, so you can’t hide the code entirely!
In the future, we might formalize the concept of an “appendix” (or perhaps an “implementation section”), and allow that section to be collapsed by default. Or we might go so far as to make notebooks hierarchical, and allow you to embed notebooks within notebooks…
In any case, we’ll try to find a nice compromise that makes the code readily accessible without getting in the way of the narrative.