Explore encouraging users to not ship DEV mode to production

[addyosmani]

Do you want to request a feature or report a bug?
Feature

What is the current behavior?
Developers meaning to do the right thing will often accidentally ship DEV mode to production rather than PROD mode. This can have a significant impact on performance. Although DEV->PROD is a one line change, it's something React could explore encouraging.

There's great nuance here and I know that there's balance to be struck between the overall DX value this brings vs UX. Another challenge is that the change itself is trivial to make. It's unclear whether the right solution here is better defaults or stronger advocacy. Folks like @sebmarkbage have been acknowledging that this is a known issue so perhaps there's room for discussion to help improve this.

He's also noted that a switch from no warnings to DEV may require some folks to fix whole codebases which is also suboptimal. There may be an in-between solution worth talking about here however.

What is the expected behavior?

React encourages users to ship PROD mode to production rather than DEV. I would be open to a solution that is either provided at the library layer (or somehow tackled during build/bundling time by Webpack) that tries to ameliorate this.

This thread had a number of suggestions ranging from localhost detection, to alerts to injecting 'dev mode' messages to the DOM if used in a production environment. Something like this:

Alternatively, @TheLarkInn was proposing that we tried to standardize on ENV configs being required to better facilitate detection of messaging like this. It's unclear which of these would be the most realistic. There are likely other ideas React core might have around how to tackle the problem.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

All recent versions.

This thread from @jordwalke prompted this issue. I think he also makes a fair point regarding benchmarks, but I care about how we can help folks ship the prod experience y'all have worked on optimizing to end customers in all it's glory.

[aweary]

For reference: #8782

[sebmarkbage]

For context we already warn if we detect that you've minified a DEV version of React:

react/src/renderers/dom/ReactDOM.js

Lines 91 to 98 in 8791325

	var testFunc = function testFn() {};
	warning(
	(testFunc.name || testFunc.toString()).indexOf('testFn') !== -1,
	'It looks like you\'re using a minified copy of the development build ' +
	'of React. When deploying React apps to production, make sure to use ' +
	'the production build which skips development warnings and is faster. ' +
	'See https://fb.me/react-minification for more details.'
	);

As far as we can find similar heuristics to notify users, and maybe even more aggressively pop up a DOM dialog, we should.

[sebmarkbage]

I also want to make it clear the warnings we provide can significantly improve performance if people pay attention to it. This thread explains some rationale for why it is difficult to deploy this after the fact if it is not the default.

[aickin]

I'd also like to chime in with a suggestion of a single console.warn if renderToString is called in dev mode. Obviously, in most situations renderToString is called in node, where we can't alert or pop up a DOM dialog.

Unfortunately, I'd really like to be able to detect not just if NODE_ENV is set to production, but also if process.env.NODE_ENV has been compiled out. Does anyone know of a way to do that?

[addyosmani]

Thanks for the thread @sebmarkbage and I acknowledge the difficulties of deploying after the fact. I'm also appreciative of the current warnings. It appears that some developers may not check the console output of their deployed sites as often as they could. It's a good first step however.

As far as we can find similar heuristics to notify users, and maybe even more aggressively pop up a DOM dialog, we should.

I'd be grateful for improvements to the heuristics used to notify users. A more aggressive DOM dialog would go a long way in helping. It would ensure the site continued working for end-users but provides an active hint that there are low-hanging perf fruit developers can pick.

The alternative is that we find a way to fix this at a build-tool / ENV level as mentioned in the original post. That would avoid any DOM-injection being necessary.

[aweary]

Injecting any messaging into the DOM seems dangerous and a little too assuming. That opens up the possibility of end users getting unexpected and confusing alerts which seems unacceptable IMO.

@TheLarkInn was proposing that we tried to standardize on ENV configs being required to better facilitate detection of messaging like this

This feels like the ideal space to address this. It's a build issue and should be, if possible, addressed by the build tools.

[surma]

Anecdotal: Warnings in the console have been gone unseen (or ignored) in the past. I have no hard numbers here, but I think console-based warnings are not enough. I agree with @addyosmani that a DOM-based warning would go a long way.

[aweary]

@surma maybe they should use console.warn or console.error for better visibility 😉

I don't see how it would be acceptable in any scenario to inject content into an application only when it's running in production. You're making a huge assumption that the message would be caught before the application was pushed to actual users, where the message could potentially hurt UX in a major way.

[sebmarkbage]

Btw, we're going to be add more comprehensive error handling support in Fiber so that you can replace components that have failures (thrown errors) with custom error views. Even in the default scenario we're likely going to be very aggressive, and just remove that component from the tree if it errors so you're really going to want to have a custom error UI for your users anyway.

We might be able to trigger such an error for this warning.

[surma]

I honestly don’t think that console.{error,warn} over console.log would have changed anything. As I said, that story is anecdotal.

I am also not saying that showing a DOM dialog is the solution. It’s something I’d personally be comfortable with, though. If staying in dev mode has negative impact, at least users would know that something is wrong and probably starts hitting the “Help” button or something.

Bottom line: I think frameworks need to get in the developer’s face at some point. I’d love to brainstorm on this to see what steps and compromises framework authors are willing to take to prevent people from deploying in dev mode in the future.

[acdlite]

What if React just doesn't work at all unless you provide an environment, regardless of whether it's development or prod? That way there's a conscious choice being made one way or the other.

[jide]

About the message injected in the DOM, it could be disabled using a global or something. No big deal IMO. If you disable it, you kind of acknowledge you know what you're doing.

Problem with a console message is that sometimes people log a lot of things, or have other warnings they ignore, and it's easy to not see that first console message past the scroll...

[jide]

With a mandatory env, inevitably boilerplates etc. will set the env var so you can just start using it I'm afraid :/

[aweary]

I honestly don’t think that console.{error,warn} over console.log would have changed anything.

Do you think its a problem with developers just not checking the console, or the console being overloaded with warnings? Could this be (partially) addressed with a more general approach regarding developer education?

I am also not saying that showing a DOM dialog is the solution. It’s something I’d personally be comfortable with, though. If staying in dev mode has negative impact, at least users would know that something is wrong and probably starts hitting the “Help” button or something.

I understand that, but I'm just saying I don't think its a solution let alone the solution. Its good that you're comfortable with it, but I think it's better to err on the side of caution and assume that most people don't want unexpected errors displayed to their users.

Bottom line: I think frameworks need to get in the developer’s face at some point. I’d love to brainstorm on this to see what steps and compromises framework authors are willing to take to prevent people from deploying in dev mode in the future.

I am 💯 for getting in the developer's face, but it's important to do it at the right place. To me, that's the build step, not production.

About the message injected in the DOM, it could be disabled using a global or something. No big deal IMO. If you disable it, you kind of acknowledge you know what you're doing.

Having it enabled by default is just as bad as not making it configurable: the default behavior could result in unexpected behavior for the end user. If anything it should be disabled by default, but then that defeats the entire purpose since developers could just fix the initial problem once they're aware of it.

Problem with a console message is that sometimes people log a lot of things, or have other warnings they ignore, and it's easy to not see that first console message past the scroll...

I totally get that, the console can get crowded and it's easy to miss stuff. But it's crowded for the exact reasons I'm arguing: it's the place the provide developers with feedback or errors. It's out of the way of the user experience, which injected messages aren't.

[jide]

Makes sense, I understand the reasonning.

Well maybe make the thing pop out using console formatting would be something at least.