-
-
Notifications
You must be signed in to change notification settings - Fork 32.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
module naming convention is not intuitive #1793
Comments
I saw in the documentation that this is the preferred way of importing material-ui-libs. However I import the modules, using src/index.js, in this format which sort of answers your question in this issue.
Are there any reason why I should not import using this method? |
in this way of importing modules, you're importing the entire library. If I'm not mistaken, when packaging using Hence, when importing file-by-file, the packaging mechanism takes only modules in use. |
Yeah, just created a small test project (gulp/browserify) to check myself and you are correct. The size differed a couple of hundred kilobytes when only importing RaisedButton. In that case I support the proposition in this issue. |
@zivl Thanks for opening this issue. I think this change can be made in v0.13.0 which will happen in 3 weeks or so. |
I like this idea too 👍 |
@oliviertassinari can this be closed in favour of #2679 ? |
when using ES6
import
or NPMrequire
for loading modules, naming convention is not intuitive as you expect to.For example:
Instead of:
I would rather import it as follows:
See the difference? the modules I'm importing has the same name of the component's name as in the documentation site (http://material-ui.com/#/components/left-nav).
I know it might cause a little backward compatibility issue but this can be workaround easily by generating aliases or even keep both of the files for a few versions, with the appropriate deprecations messages (in
code
and inconsole
)The text was updated successfully, but these errors were encountered: