Clean up kwargs and config

[alexcjohnson]

Right now we have a lot of args to dash.Dash. Some of them may be unnecessary, some have confusing names. Then there are other settings that can only be done after constructing the app, by digging into sub-objects and changing the defaults that were set during construction. Ideally it seems to me we should make ALL configuration possible through the constructor, but perhaps using a smaller set of kwargs that accept objects. These kwargs and objects should map cleanly onto attributes that you can modify later if necessary (and possible).

Currently here's what we have, AFAICT. (Env vars are included as well, where available.)

Constructor args:

• misc:
  • name (DASH_APP_NAME)
  • server
  • compress
  • suppress_callback_exceptions (DASH_SUPPRESS_CALLBACK_EXCEPTIONS - can we remove the misspelled supress_callback_exceptions fallback? The fix dates to 2017)
  • components_cache_max_age (DASH_COMPONENTS_CACHE_MAX_AGE can we remove, as we have cache-busting urls?)
  • plugins
• url modifiers:
  • assets_url_path
  • assets_external_path (DASH_ASSETS_EXTERNAL_PATH)
  • url_base_pathname (DASH_URL_BASE_PATHNAME)
  • routes_pathname_prefix (DASH_ROUTES_PATHNAME_PREFIX)
  • requests_pathname_prefix (DASH_REQUESTS_PATHNAME_PREFIX)
• asset behavior:
  • assets_folder
  • static_folder (can we remove?)
  • assets_ignore
  • include_assets_files (DASH_INCLUDE_ASSETS_FILES)
• page content:
  • meta_tags
  • index_string
  • external_scripts
  • external_stylesheets
  • show_undo_redo
• unused: **kwargs - only used to look for unused csrf_protect kwarg that became obsolete in 2017 - csrf_protect will be removed but I'll use the same mechanism to help with kwargs I'm removing here.

run_server args: The idea here is that these may have different values when running locally than when deployed - seems like this division has been done well but a few potential tweaks mentioned below.

• dev tools (set through enable_dev_tools, or run_server with dev_tools_ prefix)

  • debug (DASH_DEBUG, no prefix from run_server)
  • ui (DASH_UI - I know it fits the pattern but as an env var this name is confusing)
  • props_check (DASH_PROPS_CHECK)
  • serve_dev_bundles (DASH_SERVE_DEV_BUNDLES)
  • hot_reload (DASH_HOT_RELOAD)
  • hot_reload_interval (DASH_HOT_RELOAD_INTERVAL)
  • hot_reload_watch_interval (DASH_HOT_RELOAD_WATCH_INTERVAL - this is in seconds but hot_reload_interval is in msec, can we change one so they match?)
  • hot_reload_max_retry (DASH_HOT_RELOAD_MAX_RETRY)
  • silence_routes_logging (DASH_SILENCE_ROUTES_LOGGING)

• run_server options not for dev tools:

  • port
  • **flask_run_options

Mutating app attributes after instantiation:

• CSS / JS

  • app.scripts.config.serve_locally (add constructor arg to set serve_locally default for both?)
  • app.css.config.serve_locally
  • app.scripts.config.infer_from_layout (unused? remove?)
  • app.css.config.infer_from_layout (unused? remove?)

• app.config: all are available from the constructor. Suggestion: use only the constructor in docs, take out the item that cannot be modified post-init. If we want to keep config as a public part of the interface, standardize what is and isn't included - this seems like a pretty random subset.

  • suppress_callback_exceptions - config used in docs (in fact, constructor arg is never used)
  • routes_pathname_prefix - CANNOT BE MODIFIED, used in __init__
  • requests_pathname_prefix
  • include_assets_files
  • assets_external_path
  • components_cache_max_age

[byronz]

• app.scripts.config.serve_locally (add constructor arg to set serve_locally default for both?)
• app.css.config.serve_locally
• app.scripts.config.infer_from_layout (unused? remove?)
• app.css.config.infer_from_layout (unused? remove?)
• app.config: all are available from the constructor. Suggestion: use only the constructor in docs, take out the item that cannot be modified post-init. If we want to keep config as a public part of the interface, standardize what is and isn't included - this seems like a pretty random subset.

Maybe we should try to align with the flask config vernacular? http://flask.pocoo.org/docs/1.0/config/

[alexcjohnson]

align with the flask config vernacular

Seems like a reasonable principle, what would that look like specifically?

[byronz]

align with the flask config vernacular

Seems like a reasonable principle, what would that look like specifically?

http://flask.pocoo.org/docs/1.0/api/#flask.Config sth like the Config class, but can be simpler