issue_comments: 1615997736
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-1615997736 | https://api.github.com/repos/simonw/datasette/issues/2052 | 1615997736 | IC_kwDOBm6k_c5gUiso | 9020979 | 2023-07-01T16:55:24Z | 2023-07-01T16:55:24Z | CONTRIBUTOR |
Thank you @asg017 ! I've pushed both suggested changes onto this branch.
If we are OK with having a build system, it would free me up to do do many things! We could make datasette-manager.js a server-side rendered file as a "template" instead of having it as a static JS file, but I'm not sure it's worth the extra jump in complexity / loss of syntax highlighting in the JS file. In the short-term, I could see an intermediary solution where a unit test in the preferred language was able to read both
This sounds good to me. I'm not sure how to add a settings flag, but will be interested to see the PR that adds support for it.
I'm comfortable to wait until we have a realistic usecase for this. In the short term, I think we could give plugins a way to grant access to a "public API of other plugins", and also ask to be notified when plugins with other names have loaded, but don't picture the datasette manager getting more involved than that.
Neat, thanks for compiling this list! Just curious, is there a query that can be used to compile this programmatically, or did you identify these through memory?
I look forward to trying this out 👍 |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
1651082214 |