This repository was archived by the owner on Jun 4, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR enables outputs to be updated clientside with user-defined JavaScript code. It enables users to replace certain Python callbacks with JavaScript callbacks for faster updates, lighter server load, and re-usable components+logic groups.
Unlike the Python callbacks, the JS callback signatures are embedded in the app layout. In this way, it's similar to the approach discussed in https://community.plot.ly/t/could-output-be-moved-inside-the-components-to-improve-readability/17178/2, except done clientside in JavaScript.
Embedding the function signatures in the layout has a couple of main advantages:
This PR introduces two new serializations: the function signatures and the clientside version of
Input
/State
. These objects are serialized within the initial layout. Here's an example of what this looks like:This implementation differs from previous attempts in a few ways:
figure.layout.title
) - only top level properties can be updated. In this way, it mirrors the Python callbacks.window[namespace][function]
and descriptions the arguments of that function (which can be a combination of constants & deferred-evaluated Input and State objects)This feels to me like the appropriate level of abstraction: very little "magic", pretty similar to Python callbacks, and still quite fast and powerful. It also requires very little backend integration, so all Dash backends (Python & R) can easily have the same interface and community members will be able to re-use the same clientside snippets.
Here are four examples of apps built with clientside that demonstrate different features.
Serverside initial data + clientside filtering
with the following clientside function in
assets/my_functions.js
:Example 2 - Serverside "Refresh" button + clientside graphing & filtering
Same as above, but with dynamic data, refreshed via a serverside function
Example 3 - Chaining clientside + serverside callbacks
Mix and match! The DAG remains alive and well - callbacks, no matter where they are executed, will wait their turn.
with the following
assets/my_functions.js
(my_functions.js
could be named anything) file:Example 4 - Adding rows & columns to a table via clientside functions
This is where clientside could shine - the simple operations between components: adding rows to tables or updating dropdowns.
with the following
assets/you_name_it.js
functions: