Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

On the server :

The classname generation should occur once

On the client:

The classname generation should occur once

Both classnames generation should match

===========

I should be able to avoid using MuiThemeProvider at the root of my app while still be able to disable classname generation

I should be able to use MUI on a route and not on another

disabling classname generation should be for the whole tree, even if I got multiple sub MuiThemeProviders

Current Behavior

On the server :

The classname generation occur twice

The first one when using apollo's getDataFromTree

The second one when using reactDOMServer's renderToString

On the client:

The classname generation occur once, and doesn't match the one made by the server

The client classname generation matches the first server classname generation, but the classnames rendered on the react components are thoses from the servers's second classname generation

This is because to disable classname generation on one of the renders, I am forced to use MuiThemeProvider at the root of the tree, so i can dynamically pass "disableStylesGeneration"

Concerns

But what if I dont want to have MuiThemeProvider at the root of my App ?

In the most cases, the visitor will only hit the home page, so no need to make the server render an useless component

Also, what if I got the multiple MuiThemeProvider pattern ?

Steps to Reproduce (for bugs)

I made a repository to illustrate the problem

https://github.com/Aetherall/MUI-issue

Context ( based on https://github.com/Aetherall/MUI-issue )

I got a SSR app with two Pages

Home : No MUI

Dashboard: MUI

Multiple: MUI - Multiple Nested Providers

I don't want to use MuiThemeProvider at the root of the App, because it would mean useless execution for the majority of the visitors, which only visit Home

Idea

The solution would be to make MuiThemeProvider get the "disableStylesGeneration" from context, and use that if no props are provided

Then, we just have to make a component which takes a disable bool prop

The component just inject the disableStylesGeneration value in the context depending on the value of his disable prop

Tech
Version

Material-UI
^1.0.0-beta.31

React
^16.2.0

react-jss
^8.2.1

Issue 2:
I've started analyzing material-ui part (quite big as it turned out) of my application bundle. My app is very simple for now, I use not many different widgets, so I was quite surprised seeing modules like Popover inside the bundle. I've traced dependency graph and I found quite a long path from Select (which I consciously use), through SelectInput and Menu modules, to that Popover thing. Why would I need it, I asked myself, I use only native Select! Quick look at source code of SelectInput gave me the answer: module Menu, which depends on Popover, is eagerly loaded even if it's not actually used. render method of SelectInput returns early in native branch of code and this is obviously not traceable by any three-shaker.

I don't have extensive experience with material-ui, so I don't know if native select is the only such case or that pattern (I mean conditional usage of component based on runtime properties) is common in the project. Are you interested in optimizaton of this? I suppose for big and large projects, using a lot of different UI components, it's not an issue at all, as that Popover component will be used in some other place eventually. For me, personally, savings are quite significant, though. Removing Menu and all its dependencies shrinks my bundle by 8% (11.5 kB gzipped).

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

Expected Behavior

I'm able to use native select component without loading bunch of components used by not-native implementation.

Current Behavior

No matter if I use native or custom select, I have all code required by the latter one in my bundle.

Steps to Reproduce (for bugs)

https://codesandbox.io/s/p79koy741j

Quite a lot of dependencies for a single native select, don't you think?

Context

It affects performance somehow (I cannot provide you real numbers, but think of downloading 11.5 kB and parsing around 50 kB of never used JS). And performance matters, right?

Your Environment

Tech
Version

Material-UI
1.0.0-beta.33

React
16.2.0

browser
any

etc
-