🏠 back to Observable

Improve the output for an import statement

#1

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

4 Likes
#2

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.

5 Likes
#3

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
#4

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
#5

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:

image

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

7 Likes
#6

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

#7

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

#8

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

#9

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

4 Likes
#10

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.

3 Likes