home / github / issue_comments

Menu
  • Search all tables
  • GraphQL API

issue_comments: 1546362374

This data as json

html_url issue_url id node_id user created_at updated_at author_association body reactions issue performed_via_github_app
https://github.com/simonw/datasette/pull/2052#issuecomment-1546362374 https://api.github.com/repos/simonw/datasette/issues/2052 1546362374 IC_kwDOBm6k_c5cK54G 9020979 2023-05-12T22:09:03Z 2023-05-12T22:09:03Z CONTRIBUTOR

Hey @cldellow , thanks for the thoughtful feedback and describing the "lazy facets" feature!

It sounds like the postTask API might be relevant for the types of network request scheduling you have in mind.

Addressing your points inline below:

It might also be nice if the plugins could return Promises.

Were you picturing that the whole plugin config object could be returned as a promise, or that the individual hooks (like makeColumnActions or makeAboveTablePanelConfigs supported returning a promise of arrays instead only returning plain arrays?

I think what you're describing can be achievable, but I want to make sure I do so in a way that addresses your need / keeps the complexity of the plugin core system at a level this is approachable .

I have a hunch that what you're describing might be achievable without adding Promises to the API with something like

fetch('/api/with-custom-facets').then(myFacets => { // reusing the go() idiom go(manager, myFacets); })

but I'd like to confirm if that's the case before investigating adding support.

bulletproof plugin registration code that is robust against the order in which the script tags load

Yes, I think what you wrote looks right to me! While it looks a little bit verbose compared to the second example, I'm hoping we can mitigate the cost of that during this API incubation phase by making it an easy-to-copy paste code snippet.

I haven't heard of the GA queing pattern before, thanks for the example. I won't have time to implement of proof of concept in the next few weeks, but I took some time to think through the pros/cons to decide whether we may want to add this in a future release:

I can see that this approach brings advantages

  • Plugin developers don't need to know the name of the datasette initialization event to start their plugin
  • Pushing a function to an array probably is easier (definitely more concise) than adding a document event listener
  • One less event listener sitting in memory

It also has some minor costs

  • A malicious plugin could choose to (or accidentally) mess with the order of the queue if multiple scripts are lined up
  • Some risk in encouraging people to mutate global state
  • (not a cost, more a moot point): changing this API may not make a meaningful difference if we're discussing whether people enter 2 vs 5 lines of code, especially if those lines are encapsulated by a function we provide (maybe something that's available on the window provided by Datasette as an inline script tag).
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
1651082214  
Powered by Datasette · Queries took 0.9ms · About: github-to-sqlite