daattali / dash2

Hi, I'm Dean 👋

I've been creating widely-used open source projects since 2014. I believe in releasing all my useful software products and knowledge into the wild so that everyone can benefit from them!

My office hours schedule for existing sponsors

You can see a list of my popular tools on my Projects page.

Please consider supporting my work ❤️ for everyone's benefit. I currently spend about half my time on open source and my other half on paying the bills by providing private consulting. My goal is to transition to only open source to reach more people with my work.

dash2's Issues

Python plotly allow you to define callbacks (and other functions?) without providing the app as a parameter - think about whether this makes sense for R

Consider allowing config parameters to be set after initialization

For example the parameters 'url_base_pathname', 'routes_pathname_prefix', 'requests_pathname_prefix' currently need to be set in the creation of the dash object (or in envvars). To me they don't sound like they should be associated with the function that creates the Dash object, because it couples the dash object right from the beginning to how it's going to be hosted. That feels like something that should either be added into the Dash object after creation, or provided to the app$run_server() function. Perhaps some sort of a "config" system, where config parameters can be added either in the constructor or in run_serve() or any time in between using app$modify_config().

Just some thoughts for later.

Add documentation to tags

Don't "depend" on dashHtmlComponents

Since {dash2} exports its own HTML tag building functions, it may be redundant to also make all the {dashHtmlComponents} functions available since there's a one-to-one mapping between those and the html list.

The package should be moved from "Depends" to "Imports" in DESCRIPTION.

This is not currently possible due to plotly/dashR#260 blocking it

Consider removing n_clicks parameter from HTML tags

All HTML tags currently have n_clicks as an argument. It can be used with any tag, but it's mostly useful just for buttons. Even if the user doesn't specify this parameter, it implicitly gets set by dash behind the scenes, so removing it still allows buttons (or any other tag) to receive an n_clicks prop in callbacks. The parameter allows users to specify a non-zero value, which I can't think of many good use cases for.

The main reason to keep it around is for consistency with other languages, and for transparency so that users know it's a propr they can use in callbacks.

Tagging @alexcjohnson

Consider using `class` instead of `className` for HTML attributes

Plotly python has "prevent all outputs" vs "prevent single output" - look into implementing it

Callbacks: make sure clientside callbacks work https://dashr.plotly.com/clientside-callbacks

set_layout can be simplified if {dash} implements better component support

Currently {dash2} manually implements fixes to plotly/dashR#257 plotly/dashR#258 plotly/dashR#259 . If they get fixed, then {dash2} code can be simplified to not include such logic.

Callbacks: consider allowing user to pass in a string instead of a input/output object

Loading {shiny} after {dash2} breaks the layout

Loading the packages in the opposite order is fine.

Example:

library(dash2)
library(shiny)
dash_app() %>% set_layout(h1('test')) %>% run_app()

Add documentation to callbacks

Callbacks: consider making property=value and property=children the default for input/output