Material-ui: Provide a configuration option for shortened classNames that doesn't depend on process.env.NODE_ENV === 'production' (React 16/Next.js bug with material-ui)

[jaredkwright]

• [x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

Because of changes in React 16, server-side rendering no longer behaves any differently in production mode than in any other environment. Libraries such as Next.js configure Webpack to compile client code in production mode. Many users need to run multiple different environments with different configurations. For example, a staging environment might need to run a production build of the app but it's NODE_ENV might be 'staging'. If this is the case, the server will always render long classnames while the client will always expect short classnames.

In Next.js, this causes the initial render to break but every subsequent render to work correctly. After tracking this bug throughout my entire stack, I determined that it comes from material-ui's configuration approach.

Rather than requiring the user to set process.env.NODE_ENV to production, allow the user to pass some kind of configuration variable that would trigger createGenerateClassName.js to operate in "production mode".

| Tech | Version |
|--------------|---------|
| Material-UI | 1.0.0-beta.12 |
| React | 16.0 |
| browser | all |
| etc | Next.js 4.0-beta.2 |

[rosskevin]

This is just my opinion, but I believe you are assuming too much by relying on NODE_ENV.

I have a similar situation, and this is how I dealt with it:

• Rails API - RAILS_ENV=production
• Front end - NODE_ENV=production
• Deployment environment - APP_ENV=staging

Similarly, in CI, I test with:

• Rails API - RAILS_ENV=test
• Front end - NODE_ENV=production
• Deployment environment - APP_ENV=test

I do not believe that use of NODE_ENV should be changed to suit deployment scenarios. It is an indication of the type of build you are using.

[oliviertassinari]

@rosskevin This is funny, we are also using this APP_ENV variable to distinguish the environments (test, staging, production, etc)

Rather than requiring the user to set process.env.NODE_ENV to production, allow the user to pass some kind of configuration variable that would trigger createGenerateClassName.js to operate in "production mode".

I agree, setting NODE_ENV=staging is a bad idea given you are going to lose all the production optimisation logic. You shouldn't mix the concerns.
But at the end of the day, createGenerateClassName.js is a temporary function that we aim to merge back to JSS. You are free to customize it to your unique needs.