-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meta: improvement ideas #1
Comments
dashboards with url path variables, to be used in dynamic pages[1]? so one could access: I'd also personally find it awesome to be able to add dashboards in the root, along (on the same level) with what would served from [1] https://github.com/simonw/museums/blob/main/templates/pages/%7Bid%7D.html |
@pax thanks for your suggestions!
Are you talking about a way to implement dashboard filters?
I hesitated doing so at first, and I went with the |
I'm not familiar with Metabase – the filters look like some controls to use after the dashboard is rendered, like, say, switching a Leaflet layer / filter after the map is loaded? That would be awesome too, but I've already seen it in the roadmap. I initially meant something in the way of niche-museums.com handling the museum page template. See {id}.html / niche-museums.com/102. But they could of course handle more variables: I could see a lot of use cases. I'm currently working on a political financing data exploring interface. We could have a dashboard for what happened with a party during a specific election – so I'd need 2 variables to gather the dashboard data. Relative to urls, you're probably right, the majority of users ignore the address. Though I imagine it would be sweet to be able to have the front page built as a dashboard. I obviously don't know how technically feasible would be to implement that. |
This is exactly what I envisioned for dashboard parameters "à la Metabase": each time you tune a parameter, you are simply updating query parameters with values for your dashboard URL. You could set it manually if you're and advanced user or use the GUI to do it for you. Metabase does it like this. Datasette already does this for query named parameters and filters. For instance, this is what I have in mind and seems to fit your use-case:
plugins:
datasette-dashboards:
my-dashboard:
title: My Dashboard
...
filters:
source:
name: Source
type: category
date-start:
name: Date Range
type: date
charts:
some-count:
title: Total number of stuff
db: data
query: SELECT count(*) as count FROM stuff WHERE source = :source AND date >= date(:date_start);
library: metric
display:
field: count
WARNING: the only issue I cannot find a solution for right now is that Datasette do not allow to specify optional named query parameters! Thus if accessing only
No sure I understand given the technical limitations. Do you have an example of your envisioned "dashboard config mark-up"? |
I can think of 2 types of filters, first the url variables, where you drill-down the necessary db data to render a widget, and in some cases, you could have in-page or in-widget filters. It might go like this: datasette-dashboards: my-dashboard: charts: some-count: query: SELECT var1, var2 FROM stuff WHERE source = :source AND date >= date(:date_start); display: fields: ['var1', 'var2'] Further wishful thinking, these in-widget filters could be of 2 kinds, exclusive (radio buttons) or cumulative (checkboxes). For a map, one could choose a variable number of checkboxes (say, show all or just a combination of data sources) and only one of each exclusive filters (show absolute OR per-capita numbers) |
@pax Here are some ongoing work:
Tell me what you think! |
@pax Some updates: starting with version 0.1.6, dashboard filters are now effective! Declaring filters in metadata (only types plugins:
datasette-dashboards:
my-dashboard:
filters:
text_filter:
name: Text Filter
type: text
date_filter:
name: Date Filter
type: date
default: '2021-01-01'
number_filter:
name: Number Filter
type: number
default: 4
min: 1
max: 10
step: 2 Declaring chart queries with filters: plugins:
datasette-dashboards:
my-dashboard:
charts:
chart1:
title: Some chart
db: data
query: SELECT count(*) as count FROM table WHERE [[ date >= date(:date_filter) ]];
library: metric
display:
field: count
chart2:
title: Some other chart
db: data
query: SELECT count(*) as count FROM table WHERE TRUE [[ AND date >= date(:date_filter) ]] [[ AND value >= date(:number_filter) ]];
library: metric
display:
field: count |
awesome. sorry, I haven't got to testing it yet – but I have a project due where dashboards would greatly help. |
Supporting other chart render engines via hooks in other datasette plugins would be awesome. This way I don't have to fork this plugin to implement another renderer. |
@rclement Is there a way to get a simple table showing some results? |
@dufferzafar No yet, but as you can see on the top comment, this is one of the components I initially envisioned to integrate! Ideally, a table component would reuse the existing Datasette implementation. If that's not possible, we need to find a simple and lightweight implementation. If you feel like it, you could prototype this |
@dufferzafar There is a new JS-based project in town from @simonw that could be the perfect candidate for a data table integration: https://github.com/simonw/datasette-table |
@dufferzafar A new |
Some ideas for other visualization types:
Some ideas to improve the dashboards system:
Misc:
The text was updated successfully, but these errors were encountered: