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:
Were you picturing that the whole plugin config object could be returned as a promise, or that the individual hooks (like 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
but I'd like to confirm if that's the case before investigating adding support.
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
It also has some minor costs
|
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1651082214 |