đź“Ł Dash v1.13.3 Release: Improved performance, clientside callback_context, many dcc.Graph & DataTable bug fixes

Dash Python
1

Update: version 1.16 has been released since this was posted.

Dash v1.13.3 is a minor release featuring:

  • Improved performance for applications displaying a lot of components
  • Upgraded Plotly.js from 1.54.1 to 1.54.3. Plotly.js is the library behind the dcc.Graph component. Many bug fixes in here including background color not updating correctly and graphs rendering too small.
  • Added support for callback_context in clientside callbacks #1240 - Thanks to @mrdawson from the community for this patch!
    window.dash_clientside.callback_context
window.dash_clientside.callback_context.triggered
window.dash_clientside.callback_context.inputs
window.dash_clientside.callback_context.inputs_list
window.dash_clientside.callback_context.states
window.dash_clientside.callback_context.states_list
  • Added support for DASH_PROXY env var to tell app.run_server to report the correct URL to view your app, when it’s being proxied. Throws an error if the proxy is incompatible with the host and port you’ve given the server.
  • Added cell_selectable property to the DataTable to allow/disallow cell selection. Use this for read-only tables. #710
    dash_table.DataTable(cell_selectable=False)
  • DataTable Bug Fixes:

:arrow_right: Official Changelog

Previous Releases

More About the Performance Improvements

In the late fall’s and winter’s releases, we worked on improving the page load speed by breaking apart the JavaScript bundles that back the component libraries and loading these bundles on-the-fly / asynchronously: If a page didn’t use dash_table.DataTable, then the JavaScript files wouldn’t be loaded until that component was rendered (either dynamically or on a separate page). We also spent time fixing how these JavaScript and CSS bundles were cached.

In this release’s performance work, we worked on the render and update performance. That is, once all of the JavaScript bundles are loaded and the requests from the data from the callbacks have finished, how long does it take to actually render or update the components on the screen? Previously, a callback update would scale O(N): rendering and updating would slow down linearly based off of the number of components that were on the page. On every callback update, we would crawl the entire layout and perform some simple checks like “do we need to display a loading state on this component?” For smaller applications, with less than 100 components it wasn’t really noticeable. However, for larger applications with 100s or thousands of components, simple callbacks could really slow down the page.
Now, render updates are O(1).

In our tests, we found that apps with 1000 components (which is easy to make with an html.Table! Just 200 rows with 5 columns), then performance is improved from 3.4s down to 1.8s. With 5000 rows of data, from 8.4s down to 3.8s :tada:

The other change we made was in how we queue up callback network requests. If many requests are made to the same callback at the same moment (e.g. imagine hovering rapidally over 10s or hundreds of points on a map), then we’ll reject some of the intermediate network requests that are queued up and whose result would ultimately be rejected by a more recent network request in the queue. A browser can only make 6 network requests to a server at any given moment, so if there are more than 6 requests being made then we’ll take the time to prune the request queue before the browser allows the next requests to be made. In apps where there are many requests being made at once, this will reduce the load to your server which will enable your server to serve more end users, faster.

This refactor lines up some interesting performance work for the future as well. If your organization is interested in performance and would like to sponsor our development, reach out to our consulting team.

Give this a release a try with

pip install dash==1.13.3

and let us know how it goes!

5 Likes
3

Seems like a bug. Can’t create a dash_table.DataTable() object.

image
image855Ă—389 21.8 KB

4

Hm, that’s odd @ga_davila . We haven’t seen that. Did this error start happening after you upgraded or is this the first time you installed dash? If you open up python and run import dash_table, do you see a result? Are there any other files named dash_table.py that your project might be importing instead of the dash_table package?

1 Like
5

Fixed… I was trying to run dash==1.13.3 with an older version of dash_table. Sorry to trigger this false alarm “issue”.

1 Like
6

Hey
Have you guys touched dcc.Loading ? it’s not working anymore. I just tested with 1.12.0 and it worked.
Thanks,

7

Hey @Omidbadr - Thanks for reporting! We just discovered a regression with loading states and multi-output callbacks. Single output callbacks and loading states still work as far as we’re aware (let us know otherwise!). A fix will be out shortly.

1 Like
8

Hi @omidbadr, we just released v1.13.4 today, which I believe resolves the issue you noted:

1 Like
9

Thanks @chriddyp and @rpkyle for addressing this issue quickly. Really appreciate it. Great work.

1 Like
10

Hello, I’m maybe wrong, or it’s maybe already noticed, but I found that in this version (or the other one, at least 1.13), the parameter “selectedData” and “clickData” of dcc.Graph are not as performant as before.

If it is used in a callback, this one is not triggered each time or triggered one more time (at first call) with no reason.

By the way, thanks for all your work, it’s really cool and usefull ! :slight_smile:

11

its there an equivalent to to ctx.outputs_list