🏠 back to Observable

Improve the output for an import statement


Currently, this is the output shown above a cell containing an import statement:

import @j-f1/fetch-from-wikipedia

This does provide some utility over just showing the code view, since the name links to the source notebook, but unlike the other visualizations, it doesn’t list the name/names imported from the statement. Would it be possible to display the names, perhaps using the same syntax as the import statement uses?

import { fetchPage } from @j-f1/fetch-from-wikipedia

alternative proposal:

import { fetchPage } from @j-f1/fetch-from-wikipedia


Great idea. And since cell names are linkable with #cellName notation — it would be even nicer if:

import { fetchPage } from @j-f1/fetch-from-wikipedia

… linked directly to the definition of the cell that you have imported.


Yes! :sparkling_heart:

Seeing that version, since all the “important” bits (i.e. the ones that change between different import statements) are highlighted by virtue of being a link, the bold is less necessary:

import { fetchPage } from @j-f1/fetch-from-wikipedia

1 Like

Yes, I currently always leave code blocks with imports pinned open, because otherwise it is impossible to search on the page for variable names defined therein. I have several times wished the names were written in the output, but never bothered filing a ticket here.

In the case of import {chart as treemap} from "@d3/treemap" (to take an example from introduction to imports), the name treemap should get into the rendered cell output. Whether the name chart does is less important.

1 Like

Thanks for the nudge on this, folks.

We’ve just deployed an update that implements this, and links directly to the imported cells.

As a bonus, you can see if you happened to fat-finger an import, and tried to import a cell that doesn’t exist:


Enjoy, and let me know if you notice any room for further improvement (we have some further ideas in this direction for later…)


Perhaps make non-existent ones red instead of gray. Or maybe that’s too distracting.


Shouldn’t it throw an error if the import doesn’t exist?


As things stand currently, the error is thrown as soon as you try to reference the nonexistent import.


This feature has been very helpful, a big improvement over the previous behavior. Thanks again Jeremy! (And Jed.)


Oh one possible modification: if the import is to a version-pinned notebook, it might be nice if the links go to the relevant version.