issue_comments: 803472278

I came up with a slightly wild idea for this that would involve pytest-style dependency injection.

Prototype here: https://gist.github.com/simonw/496b24fdad44f6f8b7237fe394a0ced7

Copying from my private notes:

Use the lazy evaluated DI mechanism to break up table view into different pieces eg for faceting

Use that to solve JSON vs HTML views

Oh here's an idea: what if the various components of the table view were each defined as async functions.... and then executed using asyncio.gather in order to run the SQL queries in parallel? Then try benchmarking with different numbers of threads?

The async_call_with_arguments function could do this automatically for any awaitable dependencies

This would give me massively parallel dependency injection

(I could build an entire framework around this and call it c64)

Idea: arguments called eg "count" are executed and the result passed to the function. If called count_fn then a reference to the not-yet-called function is passed instead

I'm not going to completely combine the views mechanism and the render hooks. Instead, the core view will define a bunch of functions used to compose the page and the render hook will have conditional access to those functions - which will otherwise be asyncio.gather executed directly by the HTML page version

Using asyncio.gather to execute facets and suggest facets in parallel would be VERY interesting

suggest facets should be VERY cachable - doesn't matter if it's wrong unlike actual facets themselves

What if all Datasette views were defined in terms of dependency injection - and those dependency functions could themselves depend on others just like pytest fixtures. Everything would become composable and async stuff could execute in parallel

FURTHER IDEA: use this for the ?_extra= mechanism as well.

Any view in Datasette can be defined as a collection of named keys. Each of those keys maps to a function or an async function that accepts as input other named keys, using DI to handle them.

The HTML view is a defined function. So are the other outputs.

Default original inputs include “request” and “datasette”.

So… maybe a view function is a class methods that use DI. One of those methods as an .html() method used for the default page.

Output formats are a bit more complicated because they are supposed to be defined separately in plugins. They are unified across query, row and table though.

I’m going to try breaking up the TableView to see what happens.