Material-ui: [Build] Create a tool to build a standalone version of Material-UI

[daniellewissc]

it would be really convenient for projects where a node based build step is inconvienent, like for a website not hosted on node, but i do understand the difficulties when both the logic and style languages are compiled. Any thoughts?

[hai-cea]

I think we'll need to do #173 first.

[EricHan0723]

so we can use compiled js and css files soon?

[hai-cea]

@EricHan0723 in v0.7.0 we're compiling all jsx to js and soon all of the css will be going into the js files. See #30

[l4u]

:+1:

[currentoor]

@hai-cea what's left to do for making a CDN version of Material-UI?

[kenbier]

:+1:, could really use a CDN version.

[currentoor]

Hey guys I'm bumping this thread again. Does anyone know what is outstanding to put this lib on a CDN?

[oliviertassinari]

@shaurya947 Was working on it last week.

[shaurya947]

This will be my focus over the next couple weeks.. will update you guys as progress happens.

[currentoor]

Awesome!

[justjacksonn]

Currently I deploy my app in a WAR file for a JEE container. To do this, I use WebPack and build the bundle.js file. My index.html page pulls that down. I bundle the index.html page as my welcome page in the web.xml and so far it seems to work. At least for building it all in a WAR file and deploying it to Tomcat or Jetty.

[shaurya947]

@justjacksonn we're taking a (slightly) similar approach. material-ui.com will have a new form page for a custom build where you can select the version of MUI you want, the components you want (or all of them), and whether or not you want to minify the output. A heroku app in the backend will use webpack to generate the custom build for you and let you download it. Then you could just include that custom build file in your html page and start using MUI components.

Note that this won't really be a _true_ CDN. The form on material-ui.com will send a query string to the heroku app to indicate the version and components for the custom build. Although this URL with the query string can be straight up included in your html page, we do not recommend doing so. It will potentially be slow because a dynamic build needs to happen at the back. We are thinking of ways to cache and optimize, but we have to consider certain space / time trade-offs.

[currentoor]

@shaurya947 that is even better than _true_ CDN IMO!

[justjacksonn]

Agreed with currentoor.. would rather have all the components in my page available offline than rely on CDN. I think CDN makes sense in a few cases, but what you describe for this sounds better. Ofcourse I use the react import feature to import the components so I dont need this my self.

[shaurya947]

@currentoor @justjacksonn @oliviertassinari @TheSeldonPlan @daniellewissc @hai-cea @EricHan0723 @l4u the project is here if you guys would like to follow along.

It is at the stage where webpack-uglified builds (with source map) can be produced locally for all MUI versions that depend on React 0.14.x.

To do:

• find out how to push bundle file through for download (might consider zipping if source map is there too)
• look into handling multiple request at the same time (and necessary code changes)
• create bare-bones form on material-ui.com so that app can be set up on heroku and be field-tested

After that:

• iterate and improve
• options for minifying, uglifying, and including / excluding source maps
• look into making previous versions of MUI available (at least those that depended on React v0.13.x)
• caching for source files and build files

[currentoor]

@shaurya947 any chance you could avoid including React itself in the output? Between all the different React libs (dom, addons, minified) it is a lot easier to manage React dependencies explicitly.

[shaurya947]

@currentoor this was one of the first design decisions @hai-cea and I made.

The thing is that we're doing an npm i to get the source files for Material-UI (which installs React too since it's a peer-dependency), and then leveraging webpack to resolve all dependencies and build the output -- which would fail without React.

Personally, I feel it shouldn't be an issue. Right now, my focus is to get the newer MUI versions (that depend on React >= 0.14.0) up and running -- so we're using React and ReactDOM accordingly. After that, we'll work on getting at least the last few React v13-compatible MUI versions up and running. Moreover, the fact that we include the React that's _supposed_ to work is one less headache for the developer, no?

How I see it, to be able to exclude React from the build, we would have to build without webpack, which entails doing all module-dependency management ourselves -- lots of work.

With all this being said, I'm open to any suggestions that you may have :-)

[oliviertassinari]

which would fail without React.

We could tell wepback that react is an external dependency.

I'm not going to use this cdn version, but I think that I would be better to have react outside.
Material ui releases are more frequent than react.
This would be better for cache invalidation.
Still, I'm wondering if the react-tap-event plugin will let us do it.

[shaurya947]

We could tell wepback that react is an external dependency.

Oh, I never thought about that. For now, I will focus on a working deliverable and explore this option once I am at a good point..

[kenbier]

@shaurya947 @oliviertassinari

Still, I'm wondering if the react-tap-event plugin will let us do it.

Have you seen this issue? Perhaps it will help.

[thomasantony]

+1

I am new to React (my last experience with web-development was with jQuery, 3-4 years ago). I wanted to use material-ui and I have been stuck with first having to learn how npm/browserify/gulp/watchify etc. works before I can actually code anything. I am sure that these tools are great and produce very efficient production code. However, to start off, a simple JS/CSS file that can be included in my source along with the JS files for React, Babel etc. would drastically reduce the time required to get this working. Thanks.

[oliviertassinari]

@shaurya947 Any update on the build tool?

[mbrookes]

I'm not going to use this cdn version

Neither am I, but it would be very nice to be able to link to CodePen / JSFiddle versions of the docs code examples.

[tintin1343]

@mbrookes @oliviertassinari : Does it still needs to be addressed completely?

[oliviertassinari]

Neither am I, but it would be very nice to be able to link to CodePen / JSFiddle versions of the docs code examples.

@tintin1343 Yes, it could be really useful 👍.

[vickailiu]

@shaurya947 could you give me some hint on how to include the styles portion? or shal Il modify the mui-custom-builder to let it bundle a muiStyles(for material-ui/styles)?

[mbrookes]

@vickailiu Are you using this?

I din't realise it existed!

Yes for 0.15.0 it would need to be updated to include MuiThemeProvider now that a theme has to be applied at the top level of your app.

[vickailiu]

@mbrookes I tried, but I felt like maybe https://github.com/callemall/material-ui/pull/4342 is even easier to use. Because I don't know why "mui-custom-builder" seems got some bugs and I need to run the scripts embedded one by one.

Then I switched to server-side rendering, so it doesn't really matter now.

[ricardopolo]

IMHO you should release a compiled version in CDNS. Cdnjs is a very good option in my opinion.

You can include a compiled version that includes all components.
In the future you can provide a compile version for each component, so a developer dont requiere to include the whole script. An you should not include the React.js components in your compile version, your scripts should be about material-ui and developers should be able to continue using the react.js oficial script.

[dwightware4]

Is this tool dead? It would be extremely useful.

[vasconita]

Hi again guys,

I'm not using anymore Material UI, but today I remembered this thread and I've thought that I can help with this.

I've made a build process with webpack to generate a standalone version of MaterialUI. I've made it quickly, and I have to review it before proposing a pull request.

If you want to use it or to try it, you can check my fork of material with this feature:

To generate CDN version: npm run build:cdn

This will generate the min file under umd/ folder

There is also a basic html page to test it in the same folder, named test-page.html.

As soon as I have time I'll read the material-ui contributing rules and I'll open a PR to explain what I've done.

[oliviertassinari]

@vasconita This issue hasn't moved for a long time.
I have my theory around it. A CDN version most of the time used by new comers.
People that don't know Webpack yet. So they can't help with the issue.
Once they learn webpack, they understand that a CDN is really good for prototyping and lose interest in this issue.

Thanks for proposing your help here. You may be able to join forces with #4342.

[oliviertassinari]

5796 was just merged on the next branch. Users can now run the following command to get an UMD version of Material-UI. Thanks everybody for your help.

npm install
npm run build:min

[mbrookes]

@oliviertassinari What's going on with these random unassigns? There was one yesterday. Seems like a github bug!

[geiszla]

How do I import the components from the UMD file?
if I use import { MuiThemeProvider } from 'material-ui'; it says

Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in. Check the render method ofHome.

if I use import MuiThemeProvider from 'material-ui/styles/MuiThemeProvider'; and give it the global name
'material-ui/styles/MuiThemeProvider': 'material-ui' (if I don't specify a global name it can't find the variable) it says:

Warning: React.createElement: type is invalid -- expected a string (for built-in components) or a class/function (for composite components) but got: object. Check the render method ofHome.

(it's the same for every component, not just MuiThemeProvider)

[bcherny]

@oliviertassinari Thanks for the hard work. Is the UMD build on a CDN? Jsdelivr has the wrong version, and cdnjs doesn't list material-ui at all. Material-UI is the biggest non-CDN'd dependency in my project - using a CDN'd version would be a big win for performance for me.

[mbrookes]

@bcherny Material-UI is written so that you only need to import the components that you use. If you use a UMD build, then the client would have to download the entire library, consuming excess bandwidth and memory - particularly bad for mobile clients.

[tomasdev]

@mbrookes could you provide an example? doing import { Button } from 'material-ui' using the CDN version triggers Module not found: Error: Cannot resolve module 'material-ui'

Edit: found a nasty fix on CodePen, use window['material-ui'] https://codepen.io/tomasdev/project/editor/AovoaM

[oliviertassinari]

Edit: found a nasty fix on CodePen, use window['material-ui']

@tomasdev We now host a CDN example. We are following the same pattern. I won't call it a "nasty hack".
https://github.com/mui-org/material-ui/blob/9a2973af59cb317070f556e06076891d735c22a9/examples/cdn/index.html#L29

We would have been exporting a MUI constant instead. Does it worth it?

[tomasdev]

I'm so sorry, didn't realize there was a cdn version inside the examples folder. Mea culpa.

runs away ashamed

[luminaxster]

TL;DR: https://cdn.jsdelivr.net/npm/material-ui@next/umd/material-ui.development.js