Remove redux-logger from production build

[mjclawar]

Description

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.

Implementation discussion

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.

[chriddyp]

I originally kept this in the production bundle because I expected that users could send me the console logs when they encountered bugs. It turned out that all of the bugs could be reproduced with simple examples and I haven't asked users to send me the console logs at all. So, I'm 👍 with taking these out of the production bundle.

It seems like this cannot be handled with webpack by a Dash user

I've exposed some config variables through a special hidden div that contains a JSON serialized config object. Here is where I access it in the front-end:

dash-renderer/src/reducers/config.js

Lines 1 to 10 in cef2313

	/* global document:true */
	import {ACTIONS} from '../actions/constants';
	export default function config (state = null, action) {
	if (action.type === ACTIONS('READ_CONFIG')) {
	return JSON.parse(document.getElementById('_dash-config').textContent);
	} else {
	return state;
	}
	}

and here is where it is set in the backend: https://github.com/plotly/dash/blob/94ab1e7b1bf3d56d21a57220de7309b0d19c4ca9/dash/dash.py#L243-L248.

However, I am OK with removing this and not making it configurable this way. Ultimately, I think the best solution would be to allow the user to serve a dev-build with source maps and console logging, and ship this dev build with the package. That's definitely a separate issue 🙂

[mjclawar]

I originally kept this in the production bundle because I expected that users could send me the console logs when they encountered bugs. It turned out that all of the bugs could be reproduced with simple examples and I haven't asked users to send me the console logs at all.

Definitely appreciate that. We've had more success debugging by looking at the POST network requests versus using the console logs.

Thank you for explaining more of the internals -- I very much appreciate you pointing those pieces out for future reference.