issue_comments

Made a start on this: ```diff diff --git a/datasette/hookspecs.py b/datasette/hookspecs.py index 34e19664..fe0971e5 100644 --- a/datasette/hookspecs.py +++ b/datasette/hookspecs.py @@ -31,25 +31,29 @@ def prepare_jinja2_environment(env, datasette):

@hookspec -def extra_css_urls(template, database, table, columns, view_name, request, datasette): +def extra_css_urls( + template, database, table, columns, sql, params, view_name, request, datasette +): """Extra CSS URLs added by this plugin"""

@hookspec -def extra_js_urls(template, database, table, columns, view_name, request, datasette): +def extra_js_urls( + template, database, table, columns, sql, params, view_name, request, datasette +): """Extra JavaScript URLs added by this plugin"""

@hookspec def extra_body_script( - template, database, table, columns, view_name, request, datasette + template, database, table, columns, sql, params, view_name, request, datasette ): """Extra JavaScript code to be included in <script> at bottom of body"""

@hookspec def extra_template_vars( - template, database, table, columns, view_name, request, datasette + template, database, table, columns, sql, params, view_name, request, datasette ): """Extra template variables to be made available to the template - can return dict or callable or awaitable""" diff diff --git a/datasette/app.py b/datasette/app.py index 03d1dacc..2f3a46fe 100644 --- a/datasette/app.py +++ b/datasette/app.py @@ -1036,7 +1036,9 @@ class Datasette:

     return await template.render_async(template_context)

• async def _asset_urls(self, key, template, context, request, view_name):
• async def _asset_urls(
• self, key, template, context, request, view_name, sql, params
• ): # Flatten list-of-lists from plugins: seen_urls = set() collected = [] @@ -1045,6 +1047,8 @@ class Datasette: database=context.get("database"), table=context.get("table"), columns=context.get("columns"),
• sql=sql,
• params=params, view_name=view_name, request=request, datasette=self, ```

This is a good idea - it's something I should do before Datasette 1.0.

I was a tiny bit worried about compatibility (Datasette is 3.7+) but it looks like they have been in Python since 3.0!

While you are adding features, would you be future-proofing your APIs if you switched over some arguments over to keyword-only arguments or would that be too disruptive?

Thinking out loud:

async def render_template( self, templates, *, context=None, plugin_context=None, request=None, view_name=None ):

Maybe the signature for that method should be:

python async def render_template( self, templates, context=None, plugin_context=None, request=None, view_name=None ): Where plugin_context is a special dictionary of values that can be passed through to plugin hooks that accept them - so database, table, columns, sql and params.

Those would then be passed when specific views call render_template() - which they currently do via calling BaseView.render(...), but actually the views that are used for tables and queries don't even call that directly due to the weird designed used with DataView subclasses that implement a .data() method.

So yet another change that's blocked on fixing that long-running weird piece of technical debt: - https://github.com/simonw/datasette/issues/1518

Implementation challenge: all four of those hooks are called inside the datasette.render_template() method, which has this signature:

https://github.com/simonw/datasette/blob/cb1e093fd361b758120aefc1a444df02462389a3/datasette/app.py#L945-L947

So I would have to pull the sql and params variables out of the context since they are not being passed to that method. OR I could teach that method to take those as optional arguments.

Might be an opportunity to clean up this hack:

https://github.com/simonw/datasette/blob/cb1e093fd361b758120aefc1a444df02462389a3/datasette/app.py#L959-L964

Which plugin hooks should take sql and params?

• extra_template_vars(template, database, table, columns, view_name, request, datasette)
• extra_css_urls(template, database, table, columns, view_name, request, datasette)
• extra_js_urls(template, database, table, columns, view_name, request, datasette)
• extra_body_script(template, database, table, columns, view_name, request, datasette)

And maybe these:

• render_cell(row, value, column, table, database, datasette)
• table_actions(datasette, actor, database, table, request)

I'll start by implementing the first set, then I'll think further about those "maybes".

I've wanted something like this in the past too. I think the thing to do here might be to add sql and params arguments to a bunch of the plugin hooks, such that they can see the main query that is being used on the page that they are helping to render.

While I'm working on this: https://docs.datasette.io/en/0.62/plugin_hooks.html#register-output-renderer-datasette output renderer functions take sql but do not currently take params - they should also take params.