github
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/issues/983#issuecomment-753221646 | https://api.github.com/repos/simonw/datasette/issues/983 | 753221646 | MDEyOklzc3VlQ29tbWVudDc1MzIyMTY0Ng== | 9599 | 2020-12-31T22:58:47Z | 2020-12-31T22:58:47Z | OWNER | https://github.com/mishoo/UglifyJS/issues/1905#issuecomment-300485490 says: > `sourceMappingURL` aren't added by default in `3.x` due to one of the feature requests not to - some users are putting them within HTTP response headers instead. > > So the command line for that would be: > > ```js > $ uglifyjs main.js -cmo main.min.js --source-map url=main.min.js.map > ``` | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 | |
https://github.com/simonw/datasette/issues/983#issuecomment-753219521 | https://api.github.com/repos/simonw/datasette/issues/983 | 753219521 | MDEyOklzc3VlQ29tbWVudDc1MzIxOTUyMQ== | 9599 | 2020-12-31T22:39:52Z | 2020-12-31T22:39:52Z | OWNER | For inlining the `plugins.min.js` file into the Jinja templates I could use the trick described here: https://stackoverflow.com/a/41404611 - which adds a `{{ include_file('file.txt') }}` function to Jinja. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 | |
https://github.com/simonw/datasette/issues/983#issuecomment-753219407 | https://api.github.com/repos/simonw/datasette/issues/983 | 753219407 | MDEyOklzc3VlQ29tbWVudDc1MzIxOTQwNw== | 9599 | 2020-12-31T22:38:45Z | 2020-12-31T22:39:10Z | OWNER | You'll be able to add JavaScript plugins using a bunch of different mechanisms: - In a custom template, dropping the code in to a `<script>` block - A bookmarklet that injects an extra script (I'm really excited to try this out) - A separate `script.js` file that's loaded into Datasette using the `"extra_js_urls"` metadata option, documented here: https://docs.datasette.io/en/stable/custom_templates.html#custom-css-and-javascript - A plugin you can install, like `datasette-vega` or `datasette-cluster-map` - since plugins can bundle their own script files that then get loaded on pages via this hook: https://docs.datasette.io/en/stable/plugin_hooks.html#extra-js-urls-template-database-table-columns-view-name-request-datasette | { "total_count": 1, "+1": 0, "-1": 0, "laugh": 0, "hooray": 1, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 | |
https://github.com/simonw/datasette/issues/983#issuecomment-753217917 | https://api.github.com/repos/simonw/datasette/issues/983 | 753217917 | MDEyOklzc3VlQ29tbWVudDc1MzIxNzkxNw== | 9599 | 2020-12-31T22:23:29Z | 2020-12-31T22:23:36Z | OWNER | If I'm going to do that, it would be good if subsequent plugins that register against the `load` event are executed straight away. That's a bit of a weird edge-case in plugin world - it would involve the bulkier code that gets loaded redefining how `datasette.plugins.register` works to special-case the `'load'` hook. Maybe the tiny bootstrap code could define a `datasette.plugins.onload(callbackFunction)` method which gets upgraded later into something that fires straight away? Would add more bytes though. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 | |
https://github.com/simonw/datasette/issues/983#issuecomment-753217714 | https://api.github.com/repos/simonw/datasette/issues/983 | 753217714 | MDEyOklzc3VlQ29tbWVudDc1MzIxNzcxNA== | 9599 | 2020-12-31T22:21:33Z | 2020-12-31T22:21:33Z | OWNER | Eventually I'd like to provide a whole bunch of other `datasette.X` utility functions that plugins can use - things like `datasette.addTabbedContentPane()` or similar. But I don't want to inline those into the page. So... I think the basic plugin system remains inline - maybe from an inlined file called `plugins-bootstrap.js`. Then a separate `plugins.js` contains the rest of the API functionality. If a plugin wants to take advantage of those APIs, maybe it registers itself using `datasette.plugins.register('load', () => ...)` - that `load` hook can then be fired once the bulkier plugin code has been loaded. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 | |
https://github.com/simonw/datasette/issues/983#issuecomment-753215761 | https://api.github.com/repos/simonw/datasette/issues/983 | 753215761 | MDEyOklzc3VlQ29tbWVudDc1MzIxNTc2MQ== | 9599 | 2020-12-31T22:07:31Z | 2020-12-31T22:07:31Z | OWNER | I think I need to keep the mechanism whereby a plugin can return `undefined` in order to indicate that it has nothing to say for that specific item - that's borrowed from Pluggy and I've used it a bunch in my Python plugins. That makes the code a bit longer. I'll write some example plugins to help me decide if the filtering-out-of-undefined mechanism is needed or not. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 | |
https://github.com/simonw/datasette/issues/983#issuecomment-753215545 | https://api.github.com/repos/simonw/datasette/issues/983 | 753215545 | MDEyOklzc3VlQ29tbWVudDc1MzIxNTU0NQ== | 9599 | 2020-12-31T22:05:41Z | 2020-12-31T22:05:41Z | OWNER | Using object destructuring like that is a great idea. I'm going to play with your version - it's delightfully succinct. | { "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
712260429 |