Feature Request: Allow Notebooks to programmatically attach / remove/ update files to themselves.

[triptych]

Is your feature request related to a problem? Please describe.
If I am the owner of a notebook, I would like to be able via an Observable API to programmatically attach files to that notebook.
Scenarios:

1. I have a visualization instance that I want to keep - I press some link or button and that canvas snapshot is "saved" then attached to the Notebook as a file. ( Right now I would have to manually download the image, then manually upload it to the notebook )
2. I have updated some CSV data via a Notebook interface. I want to update the attached CSV with this information. (Right now I would have to download the attached CSV, update it manually with the new text, delete the existing file attachment, and re-upload the attachment )
3. I have run some analysis on some data in the notebook. I want others who see this notebook to see the results of the analysis. ( Right now I have to download the content, zip it up, then re-attach to the notebook potentially )

Describe the solution you'd like
CRUD actions on FileAttachments via a JS api. They would still follow the same file size restrictions as normal file attachments, size amt, etc. Bonus points for being able to update a file inside an attached ZIP archive.
Again - this api would only work for the owner of the Notebook. It would simply be a convenience api around creating, updating, reading, and deleting FileAttachments.

Describe alternatives you've considered
Current alternatives are the manual creation / delete / upload via mouse clicks.
Use of LocalStorage works only for the current viewer of the notebook.

Additional context
Having a virtualized file system api would lead to some fantastic uses for Observable Notebooks with only a small addition to it's functionality.

[mootari]

I had intended to create a similar issue, but scrapped it because there were too many open questions. The problem it was meant to solve: cache the results of costly calculations and/or restricted fetches in file attachments, with an option to update them.

Some of the notes:

• Creating attachments programmatically is too dangerous, as a loop can easily screw up a user's upload quota. All updates should require manual interaction.
• The "export" action could be added to a cell's toolbar. Adding it to a cell's context menu would like cause too much clutter (unless nested menus were supported).
• Conventions could be used to avoid an intermediate modal:
  • Use the cell name as the fileattachment name.
    • Open problem: How to detect the file extension? What file format should the export be in, or should there be multiple options? As a consequence, is a modal-less export process even viable?
  • If a fileattachment of the same name exists, replace it.
    • Open problem: "Replace" currently only works if the fileattachment isn't referenced anywhere.
    • Open problem: Should old versions be kept?

An alternative I had considered was to create a draggable file object that could be dropped on the Upload area. Unfortunately this wasn't possible due to the notebook's sandboxing (afaik).

[CobusT]

Thanks for raising this feature request. It is related to an idea that we have about allowing a cell to be saved as a file attachment. That way, when you wrangle a data source (potentially from a database query, or a large dataset, or a private dataset), into something you would like to use in your visualization, you can then save that file as an attachment (in the UI) and use that file going forward.

It would assist in this fairly generic workflow:

• query some private data in a private notebook (with a database query/API token)
• wrangle the data, explore with tools such as Arquero, Plot, etc. to get to a smaller/anonymized/public view that can be shared
  - save the data as a file attachment (UI action, perhaps choose JSON, CSV)
• sever the link to the private data (or comment it out so it doesn't query for normal users)
• now you have a notebook that can be shared/published, and you could refresh the data when you need to by doing the previous 'save the data' step again (will need to figure out details about replacing existing file vs. new file, as @mootari described above)

Is this a workflow that would solve your case, @triptych ?

[triptych]

Yes, I think this "wrangle the data" and get some kind of output is a gap that this would fill nicely. I read about the kind of special needs for something like this in the data vis world, and would be perfect for my own use case of small tools that allow developers to create things and share them within the same notebook. This would also I think encourage collaborative notebooks as well.

[rossburton]

I have a related need:

• I have a notebook which visualises some JSON. This JSON is generated behind a private network so needs to be attached to the notebook, the notebook cannot fetch it. The JSON is updated nightly and I want the notebook to always have the latest JSON without me manually updating it.

A simple authenticated HTTP POST would be sufficient to update a named attachment.