Async JavaScript Lazy Loading #899
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # dash-renderer/src/actions/index.js
Marc-Andre-Rivet
requested review from
alexcjohnson and
byronz
as code owners
Marc-Andre-Rivet
changed the title
Marc-Andre-Rivet
changed the title
|
devtools were using |
|
added a shimmed test for |
alexcjohnson
approved these changes
Oct 18, 2019
This was referenced Oct 22, 2019
chriddyp
changed the title
chriddyp
changed the title
HammadTheOne
pushed a commit
to HammadTheOne/dash
that referenced
this pull request
May 28, 2021
…ash-4.17.21 Bump lodash from 4.17.10 to 4.17.21
HammadTheOne
pushed a commit
that referenced
this pull request
Jul 23, 2021
…17.21 Bump lodash from 4.17.10 to 4.17.21
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Realted to component-specific implementations:
plotly/dash-core-components#616
plotly/dash-table#554
Component loading state is exposed on the component class / function.
The renderer evals the loading state of all component types on layout changes (possibility of new component types).
notifyObserveruses this state to decide whether to go forward with callbacks or wait.Because of callback chains and multi-input & state parameters, it's not possible to only depend on the state of the current component. This may result in more overhead vs. checking out only the state of the (1) components in the dependency graph, (2) components impacted by the callback's dependency chain, but it feels like a good first implementation.
Dash now supports a new attribute on
_js_distassets:async.asynccan't be used withdynamicand is instead used to determine at runtime if an asset should beeagerorlazy. Takes three values: True,eager,lazy.This is necessary to cover cases like the dcc.Graph plotly.js dependency -- we need
window.Plotlyto be set automatically if eagerly loaded, for the value to already be set after DOM render, for legacy purposes.Special webpack plugin to redirect Dash dynamic imports correctly, byt taking into account the Dash path structure webpack-dash-dynamic-import
Common code for all async components to use to make the renderer aware of their 'aysnc' nature dash-component-plugins -- this was made more general with thoughts of adding other plugins here (e.g. the private layout could be abstracted here for components that need it)
Test Dash resolution of
asyncwith different values foreager_loadingandforce_eager_loadingflagsValidate
lazyrequests are not loaded right away (e.g. DOM comparison)Test
setAppIsReadywith shim -- make sure callbacks are blockedAdditional performance work that could be done here or spin off new PRs:
<head>, the other can stay were it is atm<head>instead of<body>-- wait for DOM from therecore-jsin renderer, externalized for all other components (renderer to pullallinstead ofusage) -- need to coordinate targets?v=x.y.zwith the version instead of the timestamp -- keep using the timestamp for debugIn order of priority / potential gains, stopping cache busting in production code is probably the biggest (and easiest) gain we can get.