OBSOLETE has been merged into dash
Home Page: https://github.com/plotly/dash
License: MIT License
This repository has been merged into the main dash repo
This Dash Renderer is a modular front-end for Dash. To learn more about Dash, view the user guide.
The comment here states that in case an event triggers a callback, the json will contain event: {'id': 'graph', 'event': 'click'}. Despite that, a few lines below we see payload.event = event;.
I am not sure which behavior is intended, however I would strongly prefer the one specified by the comment because I'd like to get the event emitter, and because the backend is free to disregard information it doesn't need.
Mocks here: https://www.figma.com/proto/icviajRVLhC69Ud0OW7dKe/dev-tools?node-id=162%3A2
This involves two things:
dash-renderer library.@rmarren1 has written the skeleton UI for dash dev tools #64. @valentijnnieman will work off that branch to implement the UI on top of it.
I haven't tested this thoroughly, but looks like it might be the case that when a dcc input component is included in a layout but is not registered with a callback, when any callback runs and the page is updated, the unregistered component's input contents are cleared. eg a dropdown that had a user selection made is reset to its initial value. If the component is then registered as a State of a callback whose value is is ignored, the initial value is then preserved as expected after a callback updates.
See this discussion: https://community.plot.ly/t/callbacks-clearing-all-unconnected-core-components-values/7631
While having unused components is probably an unlikely scenario in a completed app, it's certainly going to be confusing behaviour if someone has created a complete layout and is then going through implementing and testing callbacks incrementally -- as occurred in that discussion.
(hopefully I landed this in the right repo!)
Vega security scanner complained about some GET requests under
/platform/_dash-component-suites/dash_renderer/ with warning:
Character Set Not Specified
Is this a real issue? Could it be fixed?
The Dash-render toolchain is out-of-date and is the source of critical security vulnerabilities.
The toolchain should be updated. Also any packages that can be updated should be updated.
During security/pen testing /_dash-component-suites/dash_renderer/foo.js [GET] request resulted in 500 Internal Server Error instead of 404 Not Found which should be returned for not existing paths.
Exception on /_dash-component-suites/dash_renderer/foo.js [GET]
Traceback (most recent call last):
File "/app/venv/lib/python3.6/site-packages/flask/app.py", line 2292, in wsgi_app
response = self.full_dispatch_request()
File "/app/venv/lib/python3.6/site-packages/flask/app.py", line 1815, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/app/venv/lib/python3.6/site-packages/flask/app.py", line 1718, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/app/venv/lib/python3.6/site-packages/flask/_compat.py", line 35, in reraise
raise value
File "/app/venv/lib/python3.6/site-packages/flask/app.py", line 1813, in full_dispatch_request
rv = self.dispatch_request()
File "/app/venv/lib/python3.6/site-packages/flask/app.py", line 1799, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/app/venv/lib/python3.6/site-packages/dash/dash.py", line 417, in serve_component_suites
self.registered_paths
Exception: "dash_renderer" is registered but the path requested is not valid.
The path requested: "foo.js"
List of registered paths: {'dash_renderer': ['[email protected]', '[email protected]', 'bundle.js', '[email protected]', '[email protected]', 'bundle.js', '[email protected]', '[email protected]', 'bundle.js'], 'dash_html_components': ['bundle.js', 'bundle.js', 'bundle.js'], 'dash_table_experiments': ['bundle.js', 'dash_table_experiments.css', 'bundle.js', 'dash_table_experiments.css', 'bundle.js', 'dash_table_experiments.css'], 'dash_core_components': ['plotly-1.41.0.min.js', 'bundle.js', '[email protected]', '[email protected]', '[email protected]', '[email protected]', '[email protected]', 'plotly-1.41.0.min.js', 'bundle.js', '[email protected]', '[email protected]', '[email protected]', '[email protected]', '[email protected]', 'plotly-1.41.0.min.js', 'bundle.js', '[email protected]', '[email protected]', '[email protected]', '[email protected]', '[email protected]']}
There are a couple of functions we're using in our tests, for example the wait_for style functions in the utils.py file, that we could update to use https://selenium-python.readthedocs.io/waits.html instead of our own functions.
The loading symbol css I am using, works just fine when I load the dash apps locally. However when I load them in a docker container it doesnt work. I have tried both loading it as an external css and as a file within assets in my root directory.
OS: Windows 10
Commit: Latest master (25e4c56)
Node version: 8.9.4
npm version: 5.6.0
> [email protected] lint C:\dev\Daedalus\lib\dash-renderer
> eslint --quiet --fix .
npm info lifecycle [email protected]~postlint: [email protected]
npm info ok
npm info lifecycle [email protected]~posttest: [email protected]
npm info ok
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info ok
npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info lifecycle [email protected]~prebuild-prod: [email protected]
npm info lifecycle [email protected]~build-prod: [email protected]
> [email protected] build-prod C:\dev\Daedalus\lib\dash-renderer
> cross-env NODE_ENV=production node node_modules/.bin/webpack --config=config/webpack.config.prod.js
C:\dev\Daedalus\lib\dash-renderer\node_modules\.bin\webpack:2
basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")
^^^^^^^
SyntaxError: missing ) after argument list
at createScript (vm.js:80:10)
at Object.runInThisContext (vm.js:139:10)
at Module._compile (module.js:607:28)
at Object.Module._extensions..js (module.js:654:10)
at Module.load (module.js:556:32)
at tryModuleLoad (module.js:499:12)
at Function.Module._load (module.js:491:3)
at Function.Module.runMain (module.js:684:10)
at startup (bootstrap_node.js:187:16)
at bootstrap_node.js:608:3
events.js:183
throw er; // Unhandled 'error' event
^
Error: spawn node ENOENT
at notFoundError (C:\dev\Daedalus\lib\dash-renderer\node_modules\cross-spawn\lib\enoent.js:11:11)
at verifyENOENT (C:\dev\Daedalus\lib\dash-renderer\node_modules\cross-spawn\lib\enoent.js:46:16)
at ChildProcess.cp.emit (C:\dev\Daedalus\lib\dash-renderer\node_modules\cross-spawn\lib\enoent.js:33:19)
at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12)
npm info lifecycle [email protected]~build-prod: Failed to exec build-prod script
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] build-prod: `cross-env NODE_ENV=production node node_modules/.bin/webpack --config=config/webpack.config.prod.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] build-prod script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Admin\AppData\Roaming\npm-cache\_logs\2018-07-26T18_57_34_933Z-debug.log
npm info lifecycle [email protected]~prepublish: Failed to exec prepublish script
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] prepublish: `npm test && npm run build-prod`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] prepublish script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Admin\AppData\Roaming\npm-cache\_logs\2018-07-26T18_57_34_971Z-debug.log
Relates to plotly/dash#480
I added in plotly/dash-html-components#40 a wildcard attribute to handle the HTML data-* attributes.
This works fine for adding a data-* attribute to an object, and within callbacks you can update this value and use it to correctly to update other callbacks.
However, this attribute is not injected into the HTML on the client side, and it cannot be used to interact with javascript and css on the client side?
Any idea where to start for fixing this issue? I am guessing that there is a subset of properties that are actually rendered in HTML on the client side, and I could add wildcard attributes there. I am having trouble finding the piece of code that does this.
After hot-reload broke in #108, we really need to add a test to make sure it still works after changes.
I have noticed that the props in the NotifyObservers component don't have their propTypes set correctly = path is used in the code as paths and dependencies, setProps are missing. Small fix, just documenting it here.
import dash
from dash.dependencies import Input, Output
import dash_core_components as dcc
import dash_html_components as html
import dash_table_experiments as dt
app = dash.Dash()
app.config['suppress_callback_exceptions'] = True
app.layout = html.Div([
dcc.Dropdown(
id='outer-controls',
options=[{'label': i, 'value': i} for i in ['a', 'b']],
value='a'
),
dcc.RadioItems(
options=[{'label': 'Tab 1', 'value': 1},
{'label': 'Tab 2', 'value': 2}],
value=1,
id='tabs',
),
html.Div(id='tab-output')
])
@app.callback(Output('tab-output', 'children'), [Input('tabs', 'value')])
def display_content(value):
return html.Div([
html.Div(id='tab-{}-output'.format(value))
])
for tab in ['1', '2']:
app.callback(
Output('tab-{}-output'.format(tab), 'children'),
[Input('outer-controls', 'value')]
)(lambda value: 'You have selected "{}"'.format(value))
if __name__ == '__main__':
app.run_server(debug=True)
Update the webpack version to latest.
$ curl -I https://unpkg.com/[email protected]/dist/react.min.js
HTTP/1.1 404 Not Found
Date: Wed, 16 Aug 2017 08:53:46 GMT
The versions hosted on CDNJS seem fine:
$ curl -I https://cdnjs.cloudflare.com/ajax/libs/react/15.4.2/react.min.js
HTTP/1.1 200 OK
Date: Wed, 16 Aug 2017 08:55:22 GMT
Maybe it's a good idea to do a HEAD request on the CDN libs at app initialization & fall back to an alternate CDN or local versions of the files if they're not found?
As in https://github.com/plotly/dash-renderer/tree/master/src/components/core
Would allow me to use the same process I'm already using to curate components from:
https://github.com/plotly/dash-html-components/blob/master/lib/metadata.json
https://github.com/plotly/dash-core-components/blob/master/dash_core_components/metadata.json
Right now, we just get a "Cannot concat on undefined".
Render may run more often than componentWillReceiveProps. So any computation on incoming props can be computed in the constructor and componentWillRecieveProps. Once computed it may be stored as component instance attributes (assigned to this). Those derived props assigned to this can then be used in render.
I haven't benchmarked anything so I don't have a good sense of the savings but if I am working in dash-renderer (likely because I am doing that now) I'll use this issue to remind myself to offer up some examples.
In current master branch, the version.py file says that dash-renderer is in version 0.13.1, but according to the CHANGELOG.md the last version is 0.13.2 as is the last version in pypi.
I'm using a modified version of dash_core_components that I built using python setup.py sdist in dev-requirements.txt like so: dash_core_components-0.33.0rc1.tar.gz this works well when not using debug mode in a Dash app, i.e. app.run_server(debug=False) but if I DO use it, all of the sudden it doesn't use the modified package. I am slightly puzzled and don't know how to fix this, any suggestions would be greatly appreciated!
A large application floods the console with logging statements due to https://github.com/plotly/dash-renderer/blob/master/src/store.js#L18. There is already a TODO here to remove the logger.
It seems like this cannot be handled with webpack by a Dash user (e.g., use a DEBUG or production flag) because the dash-renderer bundle is included separately. Should the logger be removed entirely for the dash-renderer production bundle? It is helpful for debugging during development.
One thing that I found weird when writing the Tabs component, is that the props on children components coming from Dash are not available on props.children[0].props(for example, where props.children[0] is a Tab component for instance), but on props.children[0].props.children.props. I've went around this by having some logic saying "if child.props.children exists, the props are coming from Dash, otherwise they're coming from Demo.js", but that causes weirdness when, in JS (Demo.js or perhaps a unit test), you set children on a <Tab/>, causing the logic to pick that up as "oh, these are coming from Dash" and using the child.props.children.props which is then not the props we want!
Hope this makes sense!
Hello.
Doesn't work when is rendered in a tab.
Example:
elif tab == "tab-2":
return(
html.Div([
dash_table.DataTable(
id='table',
columns=[{"name": i, "id": i} for i in df.columns],
data=df.to_dict("rows"),
)
])
)
df is empty DataFrame with 5 columns.
When "tab-2" is selected, the tab changes but the contents of previously selected tab remain.
Could you please look into that?
https://circleci.com/gh/plotly/dash-renderer/154
======================================================================
FAIL: test_simple_callback (tests.test_render.Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/ubuntu/dash-renderer/tests/test_render.py", line 461, in test_simple_callback
len('hello world')
AssertionError: 11 != 12
It'd be great if this repo could use a release process similar to plotly.js (which makes it really for me to update dependencies in the R package), that is:
dist/ folder.The MANIFEST.in file does not include the React 16 bundles, which means that updating the react version does not work in development in other projects (e.g., this PR in dash-core-components), starting in v0.12.0.
Addressing this issue requires updating the MANIFEST.in to
include dash_renderer/bundle.js
include dash_renderer/react-dom@*.min.js
include dash_renderer/react@*.min.js
to handle all react and react-dom files via blob for publishing to PyPI
On two different branch that are mostly up to date with master I get:
<script src="/assets/../dash-renderer/dash_renderer/dash_renderer.dev.js?m=1550111470.43"></script>Included on the index, which gets served the dash index.
Need more investigation.
Right now, the ._dash-loading-indicator class is a cousin of the app container. If it was the parent, then you could customize UI in your app.layout that would only appear while a callback is being executed:
app.layout = html.Div(className='display-on-loading', children='Loading')
.display-on-loading {
display: none;
}
._dash-loading-indicator .display-on-loading {
display: block;
}
The app isn't working in Safari, because the fetch isn't supported in the browser.
It results in the error ReferenceError: Can't find variable: fetch, preventing the application from starting-up.
I can see a TODO to use the whatwg-fetch, porting to this fetch polypill should fix it.
Related to plotly/dash-table-experiments#28 and plotly/dash-core-components#162
It was explained in more detail on the community boards https://community.plot.ly/t/display-tables-in-dash/4707/40?u=chriddyp:
A little context: When Dash serves the page, it crawls the app.layout to see which component libraries are being used (e.g. dash_core_components). Then, with this list of unique component libraries, it serves the necessary JS and CSS bundles that are distributed with those component libraries.
In this case, we’re serving dash_table_experiments on a separate page, as the response of a callback. Dash only sees dash_html_components and dash_core_components in the app.layout and so it doesn’t serve the necessary JS and CSS bundles that are required for the dash-table-components component that is rendered in the future.
This is a design flaw of Dash. For now, you can get around this issue by rendering a hidden dash-table-experiments component in the layout like:
app.layout = html.Div([
html.Div(id='content'),
dcc.Location(id='location', refresh=False),
html.Div(dt.DataTable(rows=[{}]), style={‘display’: ‘none’})
])
Ideally, we'd request dash's backend for the component suites on demand, rather than all upfront.
Hi
I have a dash version. I'm using these components:
dash==0.28.2
dash-html-components==0.13.2
dash-core-components==0.30.2
Suddenly I experienced that my application wouldn't work anymore. It would just stick at the "Loading..." page.
I investigated and found that dash-renderer was automatically updated to 0.20.0. That must be where there is a breaking change. Because if I revert to 0.19.0 the page is working.
I know semver says that you can't rely on major version 0, but still. It would be nice if the changelog would mention that there was a breaking change.
The current npm lint command has the --quiet, which means that when running this command in CI and will not fail the build.
Suggest splitting this in two commands
lint checks and fails on linting errorslint.fix checks and fixes linting errors if it can (retaining the current dev-side work case)The API requests that Dash's front-end makes should be configurable. In order to make them configurable, we will need to do the following things:
dash-renderer) a standalone library that can be initialized and invoked from other librariesdash-renderer to take a set of config input parametersrequest_pre and request_post parameter that will be called before and after HTTP requests with the entire request and response objects. This will enable the developer to transform the data before and after network requests.dash_renderer({
request_pre: requestPayload => {
return modifyRequest(requestPayload);
},
request_post: (requestPayload, responsePayload) => {
return modifyResponse(requestPayload, responsePayload)
}
})
So, the hooks are only the network requests. In the code, this would fit in here:
dash-renderer/src/actions/index.js
Lines 447 to 455 in 70bb93e
Note that in order for users to supply their own arguments, I believe they would need to provide their own instance of dash_renderer by overriding the index file (as discussed here: plotly/dash#265)
Hey @chriddyp! So we're having a new issue with dash-renderer==0.11.0 that was not on older versions. I think this is related to plotly/dash#133 and #22.
We are trying to render something like 40 components on page load. However, only about 20 of them actually even make a request on page load for data.
0.8.0pathname.pathname is None, we throw a ValueError, and the request to /_dash-update-component returns a 500.pathname then updates to /my/new/url/10, and requests to /_dash-update-component return the correct data based on the url.This is good enough and works, although leaves an "Updating" in the browser title.
0.11.0pathnamepathname is None, we throw a ValueError, and the first request to /_dash-update-component returns a 500. We noted that the first request is always the same, and always returns a 500.pathname then updates to /my/new/url/10, and about 20 requests to /_dash-update-component return the correct data based on the url. We noted that these are always the same requests and always return the correct data.dash-renderer thinks that all requests completed successfully.If useful, I can try and make a dummy example of this. It does, however, based on previous issues and the change made for 0.11.0 seem to be related to the event scheduler (and the dummy example may have to be quite large to mimic this issue).
For now, we have to stay on older versions of dash-renderer since the behavior in 0.11.0 is not desirable.
The changes in #22 cause the request queue to continuously grow as new updates come in since old requests are only marked as rejected and not removed from the list. Once this array reaches a couple of hundred items long, I see Chrome and Firefox slow to a crawl. Note the growth of the array is easily visible in the SET_REQUEST_QUEUE action logged in the browser console. For my app this occurs in a couple of seconds given the number of updates being made.
Adding this:
dispatch(setRequestQueue(
reject(
rejected => rejected,
getState().requestQueue
)
));
to the updateRequestQueue function
dash-renderer/src/actions/index.js
Lines 397 to 411 in 401b977
import dash
from dash.dependencies import Input, Output
import dash_html_components as html
import dash_core_components as dcc
app = dash.Dash()
app.layout = html.Div([
html.Div(id='session-id', children='id'),
dcc.Dropdown(id='dropdown-1'),
dcc.Dropdown(id='dropdown-2'),
dcc.Dropdown(id='dropdown-2')
])
options = [{'value': 'a', 'label': 'a'}]
@app.callback(
Output(component_id = 'dropdown-1', component_property = 'options'),
[Input(component_id = 'dropdown-2', component_property = 'value'),
Input('session-id', 'children')])
def dropdown_1(value, session_id):
print('dropdown-1')
return options
@app.callback(
Output(component_id = 'dropdown-2', component_property = 'options'),
[Input(component_id = 'dropdown-1', component_property = 'value'),
Input('session-id', 'children')])
def dropdown_2(value, session_id):
print('dropdown-2')
return options
if __name__ == '__main__':
app.run_server(debug=True)
Each callback is called twice, I believe that they should only be called once:
127.0.0.1 - - [13/Jan/2018 00:24:26] "GET /_dash-dependencies HTTP/1.1" 200 -
dropdown-1
127.0.0.1 - - [13/Jan/2018 00:24:27] "POST /_dash-update-component HTTP/1.1" 200 -
dropdown-2
127.0.0.1 - - [13/Jan/2018 00:24:27] "POST /_dash-update-component HTTP/1.1" 200 -
dropdown-1
127.0.0.1 - - [13/Jan/2018 00:24:27] "POST /_dash-update-component HTTP/1.1" 200 -
dropdown-2
127.0.0.1 - - [13/Jan/2018 00:24:27] "POST /_dash-update-component HTTP/1.1" 200 -
Hi, I've got a typical interactive plotting app with crossfilters on plots in multiple tabs - if I switch to plots with the exact same layout & structure on a subsequent tab, the plot interaction callbacks on the first will be lost when I switch back to it, however if I switch to a tab with layout even slightly changed (eg. just add a div in before the plot), callbacks will resume.
No callbacks (or redux actions) are fired from the javascript side when interaction is lost, so I'm assuming this is some issue in the js of dash-renderer - possibly some sort of optimisation/assumption that the plots are the same based on plot layout ...?
I started by looking at https://community.plot.ly/t/interactive-graphing-not-working-with-dcc-tab/13852, but the last comment there didnt quite replicate the bug, so I tweaked it as follows:
https://gist.github.com/nite/7b7811b2432991824edfb30c1b5a783f
I've also created a forum post here:
https://community.plot.ly/t/interactive-plots-lose-callbacks-with-tabs/15585
In dash-renderer 0.13.2 a component will have setProps === undefined if there is not dependency on its properties.
Complex components behavior can be severely impacted if they have no dependency (e.g. if no dash-table prop is used as a dependency, pagination_settings and filter expression are not updated, which prevents the UI from updating itself & shows incorrect information).
Complex components lend themselves well to this problem as there's a higher probability that they are at the top of the component "food-chain" (they depend on others but no one depends on them as they are the "final" view or result for a combination of settings)
*** Update: Do we need to do something similar for fireEvent ?
I've tested this in IE11 myself, so I'm surprised by this bug report, but perhaps we're missing a fetch polyfill: https://community.plot.ly/t/on-ie11-getting-error-script5009-fetch-is-undefined/14445
The redux logger causes a ton of output in the console, especially with hot loading.
Also, sometimes it catches component error messages and rethrows them, making the tracebacks & "launch debugger on uncaught exceptions" tools hard to use.
I'm in favor of removing redux-logger. If anyone benefits from this while developing dash-renderer, they can add it back while they are in development (but not commit it).
Here's an associated community report that is having trouble filtering out the logs: https://community.plot.ly/t/dash-renderer-dev-js-logs-messes-my-browser-console/19120
Companion issue to plotly/dash#531
Nothing special is required in dash-renderer, just removing the eventGraph and related code. But it may be useful to have this prior to multi-output (cc @T4rk1n ) and dynamic callbacks as there may be some additional dependency graph machinery to get those to work right, and it would be nice not to have to duplicate those changes for events.
I noticed that 'undo' will not work if the previous two user interactions were applied to different components. For example, if interaction 1 is applied to component A and interaction 2 is applied to component B, then the undo button will do nothing. If both interactions are applied to the same component, then the last interaction will be undone as expected.
Reproducible example:
import dash
import dash_html_components as html
import dash_core_components as dcc
from dash.dependencies import Input, Output
app = dash.Dash()
app.scripts.config.serve_locally = True
app.layout = html.Div([
html.Button(id='click', children='click'),
html.Div(id='output', children=''),
dcc.RadioItems(
id='radio',
options=[{
'label': 'good',
'value': 'good'
},
{
'label': 'bad',
'value': 'bad'
}],
value='good')
])
@app.callback(Output('output', 'children'),
[Input('click', 'n_clicks'),
Input('radio', 'value')])
def crash_it(clicks, radio):
return clicks
app.run_server(debug=True, port=8000)
Versions:
dash==0.23.1
dash-core-components==0.26.0
dash-html-components==0.11.0
dash-renderer==0.13.0
🚨 You need to enable Continuous Integration on all branches of this repository. 🚨
To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.
Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.
If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.
We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.
Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organiszation’s settings page, under Installed GitHub Apps.
Right now, if the component's properties don't update with callbacks, then it has to manage its own state. This will be a quite a bit faster as the dash-renderer re-render cycle can take a moment or two.
The standard way to check if a component should manage its own state is by checking if this.props.setProps is defined or not. For example, see the dcc.Input component:https://github.com/plotly/dash-core-components/blob/e7fcda46ec87357052f1198bf6e61ba434e46676/src/components/Input.react.js#L31-L42
In the latest dash-table project, there are many properties that can change. I would like to be able to know which properties are controlled by dash-renderer (i.e. which properties update with callbacks) and which properties should be stateful inside the table. That way, controlling the state for certain properties would remain very fast (e.g. keyboard navigation) but others would go through the entire dash-renderer lifecycle (which ends up being quite a bit slower).
Now ideally, we could solve this in dash-renderer just by making the setProps call faster. I think that this would end up being quite a bit of work. So, in the meantime, I propose passing through the set of properties that dash-renderer will manage. For example:
dashSubscribedProperties=['value']
then, the component can have logic like:
onChange={e => {
if (props.setProps && R.contains('value', props.dashSubscribedProperties) {
props.setProps({value: e.target.value})
} else {
this.setState({value: e.target.value})
}
}}
componentWillMount(props) {
this.state = props;
}
render (){
<input {...R.merge(this.state, R.pluck(props.dashSubscribedProperties, props)}
}
cc @plotly/dash
In our organization, we want to use a custom Loading react component. I've forked this repo and added our own component, but I guess it would be better if anyone could have the option to import an external react component here, instead of maintaining a forked version.
This way we could even share different loading components accross all the Dash and React community.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.