Pure Python — no JS nonsense! Unless you want to include your own JS /assets .
The callback debugger is INSANE ! It is so confidence inspiring that no matter how many callbacks you chain together, this thing has your back. It monitors your app in real-time and pulses with information as callbacks are fired.
Couldn’t find a way to run regular app=Dash() from within Python module — it seemed like it wanted me to start it from the command line as a standalone .py file. So I am invoke it in a module via app=JupyterDash() so that I can bake it into my own package. Feels like a hack.
I really want a way to pass arguments into the app during initialization rather than just relying on globals in the .py file.
The DataTable component is disappointing for a framework that is supposed to be about “Data Apps.” It’s not easy to use and it’s not easy to style. I just wound up using Bootstrap tables.
It felt like callbacks were converting all inputs to strings. Can’t use bool and ints. Kind of defeats the whole zero JS thing. Which resulted in my DataTable numbers being strings.
I wish there was an option to refresh the entire app using Interval without having to painstakingly manage the State of every callback.
JupyterDash is not a pre-built JupyterLab extension yet.
Dash datatable is powerful but it takes a lot of code to master it compared to other components. It would be awesome if it could do everything this solution does
Yeah I love a lot about Dash, but the datatables are definitely lacking when it comes to a data-driven application. You really only need tables and charting, charting works quite well, but the tables lack some of the necessary features like “drilling-down” with aggregation (the main feature that I need), etc. I think they’re making a new datatable component but it will probably only be accessible from their Enterprise suite, instead of allowing anyone to plug into it without the paywall.|
hi @HashRocketSyntax
thank you for the feedback and that extensive Medium article you wrote about us. It offers a very interesting analysis.
Regarding the areas of improvement, we’d love to learn more and offer some clarification where appropriate.
this seems like it can be done through the All-In-One (AIO) Components. Would that work for what you’re looking to accomplish?
this might be possible to do with just regular command line parsing in the if __name__ block
Would love to hear more feedback about the DataTable. What part of it was not easy to use. Why was it hard to style?
In DataTable and dcc.Input we do strings unless data types are declared as numbers. Can you please tell us more or share an example to clarify “callbacks were converting all inputs to strings”?
I don’t think that adding dcc.Interval to a callback requires changing Inputs to State. Can you please explain what you mean by manage the State of every callback. What kind of challenge are you facing?
I saw this discussion and thought I could add a few more thoughts on the DataTable.
I’ve built quite a number of Dash apps and the DataTable is definitely the component I most dread using. I think the number one issue for me is that it requires a lot of specific decisions about column formats, etc, to be made by at the time of component generation, as opposed to putting everything in the hands of the user (yes theoretically it’s possible to enable the user to customize the table, but that’s a whole extra layer of components and logic). This is particularly challenging if you don’t know the data (or even the columns) at development time.
One example:
I made a table the other day and I have a column with some large integers. With the default settings, it gets formatted to scientific notation with 3 significant figures, and there’s no way to extract the exact value. As a user, I can’t resize the column, reformat the column, or even copy-paste the value.
Other things along these lines:
quite complicated or even impossible to filter for multiple values in a column. I find the interface for sorting by multiple columns confusing as well.
I find the checkmarks to select the rows kind of clunky – can’t select multiple rows at once and unless you apply additional styling it’s hard to see which rows are actually selected. Again, fixable with some additional callbacks, but all this adds effort.
personally I find the pagination not particularly useful. I guess dynamic scrolling without loading all the data would be a pretty cool feature.
the default style seems to result in a lot of whitespace – this one I guess is relatively easy to fix with styling
This is an unrealistic expectation for a Dash component, but I feel like the gold standard model for a good data table is Excel. Very compact layout, lots of user control over the data appearance, easy and obvious selection, etc.
Haha, that’s what I’m talking about when people use table stuffs. These issues I’ve been talking about years ago since I started using dash-table.
I mentioned four points at that time, select all, pictures in cells, data drilling, and validation.
Pics in cells now have markdown support. Drilling may also use MD, but that is certainly not what the users want. And the lack of drill-down feature was a huge obstacle for me to convince the company to introduce the Enterprise Edition.
Rows and columns are always different things. But the table component doesn’t seem to have a dedicated product manager responsible?
Validation is great. But still no on-change flag.
Also, there is no way to keep the code clean only when using DT.
I’m a longtime Dash user who was sold on the super powers that Dash and other Python based data-app frameworks provide right from the get-go.
I’ll throw in my two cents around the DataTable component, having recently been working on an app that makes heavy use of it (whereas I had only experimented with it before).
I’ve also come to the same conclusion, that it still has some missing functionality and rough edges, which, in the context of a framework for building data apps, represents some considerable feature gaps, given that this component will be the workhorse of a large chunk of apps folks will be trying to use Dash to make.
I also think it’s clear that the DataTable component has had a massive amount work put into it, and it’s quite impressive what the Dash dev team have built, given that they’ve made this component entirely from scratch. I find myself comparing it to the DataTables jQuery plugin, which I’ve previously used to make record-oriented data apps and is very much a mature data table library. It’s worth bearing in mind that this project just consists of a data table and has benefited from 15 years of development, whereas the Dash DataTable is but one component in the greater Dash ecosystem that the Dash dev team maintains, and has only existed for a couple of years.
Here’s the notable friction points in the DataTable component that I’ve run into, which I think could be opportunities for the DataTable to become a mature tabular data explorer:
There’s limited support for number formatting via d3-format, however the DataTable does not expose the ability to decouple cell rendering from underlying cell values. A notable effect of this limitation is that when using Markdown rendering in cells, client-side filtering is performed on the Markdown text rather than the underlying values that would have been used to generate the Markdown, which will likely break filtering functionality (as @stu mentioned). Also when exporting the table data as eg CSV, users will get markdown strings in their export rather than raw data.
There’s no context displayed regarding the record numbers for the current page and total number of records after any client-side filtering is performed. eg: “showing 1-20 of 347 records”. This is important context for someone working their way through more than a small number of records. I was able to get this partially implemented using a client-side callback, but this seems like a low-hanging accessibility improvement that could come out of the box.
The client-side filtering ability is great, but requiring the user to learn the required querying language is not super accessible. I’m hoping that the DataTable roadmap includes adding UI components for each filter type to make these more accessible and ergonomic. A massive game changer would be a dropdown column filter pre-populated with all distinct values in that column (see here for an example). As this would be in instant data exploration capability uplift, helping you learn about your data as you filter.
There’s no simple mechanism to add an index column that just shows the rank of each row in the DataTable. I had to get around this by adding this column in the underlying DataFrame, but this has the limitation that the numbering won’t be re-indexed after client-side filtering, so you’ll see row numbers like 1,8,9,20,21 etc
And just to reiterate, these are all things I think are opportunities to build on the already amazing work that’s been done on the DataTable component!
Hi @nedned
Thank you so much for this valuable feedback. You bring up really good points about the DataTable that would definitely make this component more potent. I especially liked the point on the dropdown column filter. That’s a very useful feature.
Agree with Ned’s point that the DataTable is an impressive component given the short time and small team – I second his kudos.
I also don’t envy the decision process around further development – several thoughtful comments on this thread and all going in different directions. Tables have so many different purposes!
It really is a ddt week. I totally agree with you about the lack of directionality. This problem has existed since numerous years ago, although they did so much. The real situation is always, the features are there after your emphasis, but it just doesn’t meet the expectations. And have you guys found it? The table component is rarely used in the official demo, which is very inconsistent with our actual work. They are actually a bit out of touch.
I’m glad so many people came together to discuss this today. I also hope that the voices of us will play a role in pulling the plotly team out of those entry-level users’ cries to focus on the real bottlenecks. I really waited a long time for this.
