Unused modules in bundle

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	-

[oliviertassinari]

Will <Select native /> still be available?

@dantman Yes, we can. The <Select native /> implementation overhead is minimal. But what about?

const Select = isMobile ? MuiNativeSelect : MuiSelect;

<Select />

Maybe it’s not needed after all.

[oliviertassinari]

What about moving forward on this issue by exposing a Select and a NativeSelect component? We can share the same stylesheet and Select.render() implementation between the two versions.