Loading React + ReactDOM from cdn

[mschipperheyn]

Given that React and ReactDOM are so prevalent and therefore likely to exist in the browser cache, it seems to make sense to have an option to build the package with an option to to include React and ReactDOM statically in the HTML file.

It would make the initial load that much snappier.

Is this something that could be considered?

[gaearon]

I agree. There are currently reasons why we can’t easily do this (addons reach into React internals). But with React 16 this will no longer be a problem and I think we can reconsider offering this.

[chj-damon]

@gaearon have you offered this in the newest version of create-react-app?

[swyxio]

hi! just had the same idea too. also wanted to point out it maybe doesnt take much more effort than configuring babel: https://www.youtube.com/watch?v=2rhkgB8Cohc

edit: i meant webpack, leaving my mistake as dan responded to me below

[gaearon]

Not sure what this has to do with Babel.

have you offered this in the newest version of create-react-app?

No but I’m open to suggestions for how it should work! I think maybe we can do this automatically if we detect CDN links in the HTML? What do you think?

[czebe]

Just offer a way to customize webpack.
I believe these scripts should go into "externals".

[gaearon]

Nah, we're not going to allow to customize webpack :-) There are dozens of issues about this if you're wondering why.

[yvesgurcan]

Hello! I would love to contribute to create-react-app and this seems an easy enough project for me. I would be happy to put into practice @gaearon 's suggestion. Which files should I look at?

[andriijas]

I was thinking the way @Ayc0 used to implement vendors in #3145 could be reused for this and #3878 - Im currently working in a project where some resources are loaded via CDN statically in index.html and its far from optimal. Its pretty convenient to have one source of truth of your packages and dependencies - package.json - easier to know which versions you are using and to keep track of updates.

Anyway Im just getting started with #3878 lets see how it goes.

[Ayc0]

@andriijas I don't know if you can use the chunk plugin (or the new split chunk plugin) to replace a module by a cdn

the external field of webpack can do this I think
Maybe, we can add a field externals in the package.json that's gonna be read by webpack

[Ayc0]

https://github.com/mastilver/dynamic-cdn-webpack-plugin

[iansu]

That webpack plugin looks like a good option. Does someone want to try it out and submit a PR?

[swyxio]

giving it a shot. i think this could be an easy win.

@iansu - any thoughts on would this be a prod-only feature or both dev and prod?

[swyxio]

I have implemented this only for prod. as one might expect it shaves 30kb off the bundle size (aka react)

[chj-damon]

@sw-yx would you like to share your process that how you make it?

[andriijas]

@Ayc0 nah i was thinking we could have one central place to configure vendors and third parties

[Ayc0]

@andriijas for those kind of things, I'd like to add a config in the package.json
But, as the package.json has a standard shape, I don't know if it's a good a idea to add custom things in it
Or we could do what everyone is doing: support a cra field in the package.json and a .crarc and a .crarc.js files that contains our config

what do you think about this @gaearon ?

[swyxio]

How do you reconcile this vs. the overall philosophy of zero config? I feel like Dan is always fending off suggestions to add config to explicitly zero config things. It is -ok- to have an opinion to make the lives of a majority of users (esp those who cant figure out good defaults for themselves) better. Thats why CRA did well in the first place, no?

[Ayc0]

I think it depends on the feature: for instance the service workers
It has been added by default but it's gonna be removed because it wasn't useful for everyone

but other tools are being created (ex: react app rewired) to keep CRA with a bit of customisation

I thing CRA could be better if some options were given to the users, but in a restricted way

Here, the cdn are really related to the packages a user is using, and we cannot predict what there're gonna use

[davidjb]

If CDN loading is implemented, it'd be helpful to customise which CDN is being used for which specific resource; pretty much what @Ayc0 is saying as I understand it. It looks as though https://github.com/mastilver/dynamic-cdn-webpack-plugin is using its own modules.json under the hood, so you have to use unpkg or whatever's there -- which isn't going to suit everyone.

[swyxio]

well I'm not sure what else to do at this point so if someone wants to give clearer guidance on this I'm all ears :)

[iansu]

Unfortunately I don't think there is a clear answer here. We need to make using a CDN opt-in and we also need to allow users to choose what CDN they want to use. It doesn't look like we can do that with dynamic-cdn-webpack-plugin.

One option might be to look in index.html for CDN links and then don't bundle React and/or ReactDOM if they're present. That's definitely more complicated though and I don't think there's an existing plugin we could use to do that.

[swyxio]

I mean thats not super hard to do in Node especially if we can make rules for what looks like a cdn link. it could work. do we want to do this?

[iansu]

If we can make it work reliably then I do think it's something we want.

[czebe]

How would you handle situations when the CDN is not available? Fallback mechanism can be quite complex, impossible to define in HTML.

[swyxio]

with this proposal, CDN is opt in. you are consciously choosing to use CDN. so we don't need to handle fallback mechanism for the user. (I am learning that a lot of people dislike CDNs on principle)

[mastilver]

https://github.com/mastilver/dynamic-cdn-webpack-plugin is using its own modules.json under the hood, so you have to use unpkg or whatever's there -- which isn't going to suit everyone.

@davidjb You can already use your own implementation using the resolver options, I'm planning to add more "official" resolver (cdnjs for example)

https://github.com/mastilver/dynamic-cdn-webpack-plugin#optionsresolver

[davidjb]

@mastilver Good to know, thanks. In the context of CRA, there'd need to be customisation which mightn't align with no customising Webpack (eg @gaearon's [comment](#2758 (comment) above). Perhaps CRA having its own resolver implementation that looks up package.json or some other config location might be the answer.

[swyxio]

I think both @czebe and @davidjb might be overlooking @iansu's suggestion: "One option might be to look in index.html for CDN links and then don't bundle React and/or ReactDOM if they're present."

edit: i am unsubscribing to this issue bc i am not so keen on it anymore. hopefully yarn plug n play comes soon.

[crebbo]

Is there any plans for this feature ^ to be incorporated into create-react-app? Ideally I'm look for a sound way to exclude specified modules and to include my own cdn links. From what I can see dynamic-cdn-webpack-plugin doesn't work with create-react-app, has anyone done this well yet?

[ryouaki]

I am looking for the solution about this feature.

[ryouaki]

Nah, we're not going to allow to customize webpack :-) There are dozens of issues about this if you're wondering why.

But this is why we need eject the script from cra...... ( T_T )

[Ayc0]

If you want to modify the package.json, I don't recommand you to eject.

Instead try react-app-rewired. I'm using it on a big codebase and it works like a charm.

I'm also using it in cra2

[Kiranprajapati2719]

What about adding a custom react script allowing use of dynamic-cdn-webpack-plugin? Any possibility?

[yushengyuan1993]

there is a solution, it works for me:
apple:

/* index.html */
<div id="root"></div>
<script src="%PUBLIC_URL%/static/js/react.development.js"></script>
<script src="%PUBLIC_URL%/static/js/react-dom.development.js"></script>
<script src="%PUBLIC_URL%/static/js/react-router.min.js"></script>

banana:

/* ./src/config.js */
const React = window.React;
const ReactDOM = window.ReactDOM;
const ReactRouter = window.ReactRouter;

export { React, ReactDOM, ReactRouter };

cat:
you kan use React like this:

/* ./src/index.js */
import { React, ReactDOM } from './config.js';

ReactDOM.render(<App />, document.getElementById('root'));

// Or
/* ./src/components/tabbar.js */
import { React } from '../config.js';

class TabBar extends React.Component {
 // your code ...
}

dog:
i started learning react a few days ago, so i am still a newcomer to using react.

[jamesknelson]

If anyone still wants to do this -- which I wouldn't recommend but sometimes you get odd requirements -- you can just add some shim packages.

First, you'll need to load React from the CDN of your choice, in index.html:

<script src="https://unpkg.com/react@16.11.0/umd/react.production.min.js"></script>
<script src="https://unpkg.com/react-is@16.11.0/umd/react-is.production.min.js"></script>
<script src="https://unpkg.com/react-dom@16.11.0/umd/react-dom.production.min.js"></script>

Then, add a shims/react directory with package.json and index.js files:

{
  "name": "react",
  "version": "16.11.0",
  "private": true,
  "main": "./index.js",
  "module": "./index.js"
}

module.exports = window.React

Next, repeat this for react-dom and react-is.

Finally, update your root package.json's dependencies to point to the new shims (you may also need to nuke yarn.lock and node_modules to get the shims picked up):

{
  "dependencies": {
    "react": "./shims/react",
    "react-dom": "./shims/react-dom",
    "react-is": "./shims/react-is",
  }
}

This is a fair bit of work, and I feel like it's probably not even a good idea in most cases, but it'll let you externalize any packages you need with stock CRA.

[andriijas]

Thanks for the update @jamesknelson

The http cache in browsers isn't predictable anymore ( https://www.jefftk.com/p/shared-cache-is-going-away ). Browsers are moving a away from single http cache to partitioned cache (for security reasons).

In 2019 it's not safe to make an assumption that React is in the cache anymore. Also cheap to free hosting options for single page apps has advanced even further in the recent years.

A better way to increase performance in your apps is to work with code splitting.

Therefor its time to close this issue. Sorry for any inconvenience.