Always end up with Loading component while SSR - Webpack 4

[Bram-Zijp]

I have been trying to implement this component and technique from scratch by following the example and only including things I think I need. In every build I tried (exact copy of your Express server config and a Koa setup) Everything works fine except for the SSR. I always get the Loading component. What am I missing?

Environment:
Webpack 4
React 16

[Bram-Zijp]

Found the problem. I forgot to limit server chunks.

Webpack 4 server config:

    new webpack.optimize.LimitChunkCountPlugin({
        maxChunks: 1,
    }),

[MartinCerny-awin]

@Bram-Zijp Could you please share rest of your Webpack configuration.

I am just trying to upgrade to Webpack 4 and struggling with it a little bit.

[williamoliveira]

Having the same problem, LimitChunkCountPlugin did not help

The funny thing is that I just tried react-loadable, my SSR was loading sync and my client async, I couldnt figure out why, gave up and migrated to react-universal-component, so now my client is loading sync and my SSR async LOL

[Bram-Zijp]

I did not manage to get React Universal Component to work fully (don't recall where I stranded). However there's a fork of React Loadable with a pending pull request which I did get to work. I also commented some of my findings and particularities I had to conquer.

[williamoliveira]

That fork worked fine, thank you!
SSR and client sync finally!

But on long term I will switch to react-universal-component as I hate react-loadable disabled issues section

[ScriptedAlchemy]

PR with updated docs and code coming soon. I have just updated it locally. Should have a PR in a few days!

[Vincz]

@zackljackson Hi! Any ETA for the PR & doc? Will you update the universal-demo accordingly?
If I can help, let me know :)

[ScriptedAlchemy]

Working on updating tests! This weekend if time permits:) I’ll send you a branch link, could always use a hand testing it and of course, updating tests

[ScriptedAlchemy]

@Vincz Ig you want to be a real MVP...
https://github.com/zackljackson/extract-css-chunks-webpack-plugin/tree/webpack-4
5 failing tests...

[Vincz]

3 tests get fixed if you uncomment the chunk group merging here:

https://github.com/zackljackson/extract-css-chunks-webpack-plugin/blob/6c8a24fac380d26ec59289886b2f5b4e9a3269d3/index.js#L328

for (const chunkGroup of chunk.groupsIterable) {
    extractedChunk.addGroup(chunkGroup);
}

The property groupsIterable is a getter on _groups property (but don't have the setter). So extractedChunk.groupsIterable = xxx will not work.

[ScriptedAlchemy]

@Vincz thanks! any ideas on the last two. Most of this code has been crowdsourced through various discussions within the universal repos 😂

[ScriptedAlchemy]

it appears the main issue that remains is on the initial load, no chunks are found. However after one hot-reload. Everything comes right.

[ScriptedAlchemy]

Problems solved

faceyspacey/extract-css-chunks-webpack-plugin#60 (comment)

[chacestew]

This must have been the same issue I was having (re earlier Glitter convo @zackljackson) - looking forward to the release!

[eliseumds]

LimitChunkCountPlugin is prohibitively slow in my setup with many split points (more than 50 async chunks). Is anyone facing this issue as well? Is it possible to do SSR without it?

[ScriptedAlchemy]

@eliseumds are you experiencing this with my updated version of this plugin?

Can you give a little more context or share your webpack build configuration.

Generally no, you can’t use code split apps on node. This is well documented 😋 you can however look at optimizing the development build speed. Don’t uglify of any of that on dev servers.

Generally though, I’ve used code splitting on a very large scale. With 100 million of lines of code.
I find it hard to believe that so few files could have such significant impact on building times.

Share your webpack config and it’ll be easier to assist

[eliseumds]

@zackljackson hey Jack, I'm not even using ExtractCssWebpackPlugin on the server. The config is pretty much this:

{
  // commonConfig has loaders like Babel and file-loader (for images), and some
  // other configs like "resolve" and "mode"
  ...commonConfig,
  name: 'server',
  target: 'node',
  entry: {
    server: appConfig.serverEntry
  },
  devtool: (DEBUG || IN_TEST) ? 'none' : 'source-map',
  output: {
    filename: 'server.js',
    libraryTarget: 'commonjs2',
    path: appConfig.buildDir,
    publicPath,
    pathinfo: false,
  },
  module: {
    rules: commonConfig.module.rules.concat([{
      test: /\.s?css$/,
      use: [
        `happypack/loader?id=${appConfig.name}-server-css`
      ]
    }, ])
  },
  plugins: commonConfig.plugins.concat(compact([
    new webpack.optimize.LimitChunkCountPlugin({
      maxChunks: 1,
    }),
    new HappyPack({
      id: `${appConfig.name}-server-css`,
      threads: 4,
      loaders: [{
        path: 'css-loader/locals',
        query: {
          modules: true,
          localIdentName: '[local]_[hash:base64:3]',
          sourceMap: false
        }
      }, {
        path: 'sass-loader',
        query: {
          sourceMap: false
        }
      }]
    }),
    new webpack.BannerPlugin({
      banner: 'require("source-map-support").install({environment: "node"})',
      raw: true,
      entryOnly: true
    }),
    new webpack.DefinePlugin({
      ...mapKeys(envVars, (value, key) => `process.env.${key}`),
      __CLIENT__: false,
      __SERVER__: true,
      __DEVELOPMENT__: DEBUG,
    }),
  ])),
  node: {
    __dirname: false,
    __filename: false,
    Buffer: false,
    console: false,
    global: false,
    process: false
  },
  externals: [require('webpack-node-externals')({
    whitelist: [
      /^react-universal-component/,
      /^require-universal-module/,
      /^webpack-flush-chunks/,
      /^lean-intl\/locale-data/,
    ],
  })]
}

Compilation time goes from ~12s to ~90s. It's insane. Output file has around 7MB.

Webpack 4.10.1
babel-plugin-universal-import 2.0.0
react-universal-component 2.9.0

[eliseumds]

@zackljackson wow wow, I just noticed I was on NodeJS v8.3.0. I just updated it to v10.3.0 and it is now 50% faster!

[ScriptedAlchemy]

Always go for the free wins 😜

Your build does however look suspicious to me. Get the bundle analyzer and make sure webpack is configured for node builds. Incremental builds are a good one for boosting performance too!

[eliseumds]

For people reading this thread, even after upgrading to NodeJS 10.3, our server build was still taking longer to recompile (about 30% for a small app, and 100% for massive ones). I just found out that setting optimization.removeAvailableModules to false significantly sped it up.

[dankremniov]

I will leave it here in case if someone else will face an issue with LimitChunkCountPlugin being slow in the future. Make sure that do not generate enormous amount of redundant chunks, as we did, which is expensive for the plugin to merge. If you do - use ContextReplacementPlugin. Alternatively, you can try to replace LimitChunkCountPlugin with babel-plugin-dynamic-import-node and babel-plugin-remove-webpack in server webpack config.