issues

Motivation

• Allow plugins that add data visualizations datasette-vega, datasette-leaflet, and datasette-nteract-data-explorer to co-exist safely
• Standardize APIs / hooks to ease development for new JS plugin developers (better compat with datasette-lite) through standardized DOM selectors, methods for extending the existing Table UI. This has come up as a feature request several times (see research notes for examples)
• Discussion w/ @simonw about a general-purpose Datasette JS API

Changes

Summary: Provide 2 new surface areas for Datasette JS plugin developers. See alpha documentation

1. Custom column header items: https://a.cl.ly/Kou97wJr
2. Basic "panels" controlled by buttons: https://a.cl.ly/rRugWobd

User Facing Changes

• Allow creating menu items under table header that triggers JS (instead of opening hrefs per the existing menu_link hook). Items can respond to any column metadata provided by the column header (e.g. label). The proof of concept plugins log data to the console, or copy the column name to clipboard.
• Allow plugins to register UI elements in a panel controller. The parent component handles switching the visibility of active plugins.
• Because native button elements are used, the panel is keyboard-accessible - use tab / shift-tab to cycle through tab options, and enter to select.
• There's room to improve the styling, but the focus of this PR is on the API rather than the UX.

(plugin) Developer Facing Changes

• Dispatch a datasette_init CustomEvent when the datasetteManager is finished loading.
• Provide manager.registerPlugin API for adding new functionality that coordinates with Datasette lifecycle events.
• Provide a manager.selectors map of DOM elements that users may want to hook into.
• Updated table.js to use refer to these to motivating keeping things in sync
• Allow plugins to register themselves with 2 hooks:
• makeColumnActions: Add items to menu in table column headers. Users can provide a label, and either href or onClick with full access to the metadata for the clicked column (name, type, misc. booleans)
• makeAboveTablePanelConfigs: Add items to the panel. Each panel has a unique ID (namespaced within that plugin), a render function, and a string label.

See this file for example plugin usage.

Core Developer Facing Changes

• Modified table.js to make use of the datasetteManager API.
• Added example plugins to the demos/plugins folder, and stored the test js in the statics/ folder

Testing

For Datasette plugin developers, please see the alpha-level documentation .

To run the examples:

bash datasette serve fixtures.db --plugins-dir=demos/plugins/

Open local server: http://127.0.0.1:8001/fixtures/facetable

Open to all feedback on this PR, from API design to variable naming, to what additional hooks might be useful for the future.

My focus was more on the general shape of the API for developers, rather than on the UX of the test plugins.

Design notes

• The manager tab panel could be a separate plugin if the implementation is too custom.
• The makeColumnHeaderItems benefits from hooking into the logic of table.js
• I wanted to offer this to the Datasette core, since the datasette-manager would be more powerful if it were connected to lifecycle and JS events that are part of the existing table.js.
• Non-goals:
• Dependency management (for now) - there's no "build" step, we don't know when new plugins will be added. While there are some valid use cases (for example, allow multiple plugins to wait for a global leaflet object to be loaded), I don't see enough use-cases to justify doing this yet.
• Enabling single-page-app features - for now, most datasette actions lead to a new page being loaded. SPA development offers some benefits (no page jumping after clicking on a link), but also complexity that doesn't need to be in the core Datasette project.

Research Notes

• Relocated to a comment, as this isn't required to review when evaluating the plugin. Including it just for those who are curious.

Spotted a problem while working on this: if you grant a token access to view table for a specific table but don't also grant view database and view instance permissions, that token is useless.

This was a deliberate design decision in Datasette - it's documented on https://docs.datasette.io/en/1.0a2/authentication.html#access-permissions-in-metadata

If a user cannot access a specific database, they will not be able to access tables, views or queries within that database. If a user cannot access the instance they will not be able to access any of the databases, tables, views or queries.

I'm now second-guessing if this was a good decision.

Originally posted by @simonw in https://github.com/simonw/datasette-auth-tokens/issues/7#issuecomment-1636031702

For every command/API method there should be a link to the equivalent in the other form factor.

Maybe also link to the API and CLI reference pages too.

Spin off from #251. The ability to execute Python functions to convert and split columns should be part of the library too, not just the CLI.

e.g. I should be able to do this:

datasette App/data.db Other_App/data.db

This currently errors because you can't have two databases taking the /data URL path.

Instead, how about in this particular case assigning the second database /data-1?

Refs #943

It can go here in the documentation: https://datasette.readthedocs.io/en/stable/metadata.html#setting-which-columns-can-be-used-for-sorting

Also need to fix this sentence which is no longer true:

By default, database views in Datasette do not support sorting

Right now it's triggering any time a mutable database changes.

This feature really doesn't warrant continuing to exist. For reference: #150 and #44

Don't forget to remove it from the docs: https://github.com/simonw/datasette/blob/172da009d890aa029cff7138b4dcfd4f60948525/docs/json_api.rst#L322-L324

I named my SQLite database "Government workers" and published it to Heroku. When I clicked the "Government workers" database online it lead to a 404 page: Database not found: Government%20workers.

I believe this is because the database name has a space.

Currently if there's a null in a foreign key we get "None" displayed in the inflated view:

It would be useful if Datasette could be configured to allow CORS requests from one or more origins, as opposed to only allowing either none or "*".

This is slightly tricky because the Access-Control-Allow-Origin: https://foo.example header is only allowed to return one value per request - and according to https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS "The Access-Control-Allow-Origin header should contain the value that was sent in the request's Origin header."

This means the application code needs to have a whitelist of allowed hosts and code that dynamically changes the outgoing Access-Control-Allow-Origin header based on the Origin header from the incoming request.

Right now a super-long CREATE TABLE statement causes the table page to be even wider than the table itself:

Adding white-space: pre-wrap to that <pre> element is an easy fix:

After #272 we can finally add this hook. It will allow plugins to wrap their own ASGI middleware around Datasette. Potential use-cases include:

• adding authentication
• custom CORS headers (see #454)
• maybe gzip support?
• possibly defining entirely new routes, though that may be better handled by a separate hook

https://datasette.readthedocs.io/en/stable/full_text_search.html already has a section about csvs-to-sqlite, sqlite-utils is even more relevant.

Most of the code here was fleshed out in comments on #272 (Port Datasette to ASGI) - this pull request will track the final pieces:

• [x] Update test harness to more correctly simulate the raw_path issue
• [x] Use raw_path so table names containing / can work correctly
• [x] Bug: JSON not served with correct content-type
• [x] Get ?_trace=1 working again
• [x] Replacement for @app.listener("before_server_start")
• [x] Bug: /fixtures/table%2Fwith%2Fslashes.csv?_format=json downloads as CSV
• [x] Replace Sanic request and response objects with my own classes, so I can remove Sanic dependency
• [x] Final code tidy-up before merging to master

Datasette doesn't take much advantage of Sanic, and I'm increasingly having to work around parts of it because of idiosyncrasies that are specific to Datasette - caring about the exact order of querystring arguments for example.

Since Datasette is GET-only our needs from a web framework are actually pretty slim.

This becomes more important as I expand the plugins #14 framework. Am I sure I want the plugin ecosystem to depend on a Sanic if I might move away from it in the future?

If Datasette wasn't all about async/await I would use WSGI, but today it makes more sense to use ASGI. I'd like to be confident that switching to ASGI would still give me the excellent performance that Sanic provides.

https://github.com/django/asgiref/blob/master/specs/asgi.rst

As requested in https://github.com/simonw/datasette/issues/185#issuecomment-376614973

I've previously avoided this for performance reasons: sort-by-column on a column without an index is likely to perform badly for hundreds of thousands of rows.

That's not a good enough reason to avoid the feature entirely though. A few options:

• Allow sort-by-column by default, give users the option to disable it for specific tables/columns
• Disallow sort-by-column by default, give users option (probably in metadata.json) to enable it for specific tables/columns
• Automatically detect if a column either has an index on it OR a table has less than X rows in it

We already have the mechanism in place to cut off SQL queries that take more than X seconds, so if someone DOES try to sort by a column that's too expensive it won't actually hurt anything - but it would be nice to not show people a "sort" option which is guaranteed to throw a timeout error.

The vast majority of datasette usage that I've seen so far is on smaller datasets where the performance penalties of sort-by-column are extremely unlikely to show up.

Still left to do:

• [x] UI that shows which sort order is currently being applied (in HTML and in JSON)
• [x] UI for applying a sort order (with rel=nofollow to avoid Google crawling it)
• [x] Sort column names should be escaped correctly in generated SQL
• [x] Validation that the selected sort order is a valid column
• [x] Throw error if user attempts to apply _sort AND _sort_desc at the same time
• [x] Ability to disable sorting (or sort only for specific columns) in metadata.json
• [x] Fix "201 rows where sorted by sortable_with_nulls " bug

Probably using YAML because then we get support for multiline strings:

bats:
  db: bats.sqlite3
  name: "Bat sightings"
  queries:
    specific_row: |
      select * from Bats
      where a = 1;