It’s all started when we encountered a problem with the installation of NPM packages. Maximum call stack exceeded.

Sometimes it just happens and you try hard, cache clean — force, rebuild, rm -r node_modules, you name it. Nothing helped and we were pretty frustrated, started tracing the root of the problem.

After a couple of hours, we found out that one of the packages we are using relies on dependency hbetts/parse-repository-url but it’s been deleted. This raised a red flag because as you may know after an affair when the author of left-pad package deleted it and caused problems to thousands of others packages including node and babel, NPM decided to turn off the ability to delete your published packages after 72hours after publishing.

We searched for the hbetts organization on NPM and we did not find any packages. We found that all the packages has been moved under hutson organization.

Now the fun begins. I decided that it would be nice to have the ability to bring hbetts back to life so I created organization under my account and it worked!

Then I tried to search for it again and all the packages magically appeared in a result, but the response of each package was still 404.

So I found the package on Gitlab, cloned and re-published it under this organization which I was not even able to create and it worked like a charm with one twist, I became the author of the package!

So I tried to do it with another package, and mate, it all worked ! These packages are currently used in multiple projects, including ours which is now working after republishing. I have ability to modify them and insert malicious code, but that could be another story.

I had nothing to do with original organization hbetts so that’s why I found it pretty interesting to share.

Please note that I reported everything to NPM already and did not wanted to cause any harm. I explained everything in detail, but they still didn’t get it so I’ll update you on this.

Follow me on twitter :))

First, something from the deep soul. I tried create-react-app and I really liked it, it’s already solved a lot of my issues with that painful webpack setup nightshifts, but there are still some things that didn’t worked, let’s say just, well.

Okey so let’s start now. I will try help you in this “tutorial” to solve some issues (not only with create-react-app) that I discovered when I started boot-strapping with it, also try to help with async imports not only for react components but also with async loaded Redux code, isolated in your routes, because I didn’t found any examples of using these together.

Absolute imports

For me, it’s really important to have this. It’s one of the biggest problems that I discovered when I started. Normally you will use .babelrc to configure, but here, it’s not available, unless… you EJECT, yes it’s scares me too, and also this issue about the problem.

"scripts": {
   "start": "NODE_PATH=src/ react-scripts start",
   "build": "NODE_PATH=src/ react-scripts build",
   "test": "NODE_PATH=src/ react-scripts test --env=jsdom",
   "eject": "react-scripts eject"
}

After I came through that issue, I ended up with this solution, you can also put NODE_PATH=src/ to .env file, but I think that you really don’t want… to see your CI build falling just because you forgot to put it into it’s .env . You can replace ‘src/’ with path that you want to use as a root for your project.

You also don’t want to see how Eslint shouting at you all the time so :

"settings": {
  "import/resolver": {
    "node": {
      "paths": ["./src"]
    }
  }
}

add this into settings and you will be fine.

Move on

In this part, I will be describing parts of app that I boot-strapped with create-react-app and done some alohomora stuff on it.

App folder structure inside of src :

What we want to achieve here, is that:

• we will have our shared components together with globally used stores and code in /src/ root in main bundle.
• Code for every page in separated bundles together with Redux code.
• We also want to be able to preload some of the pages before we will try to access their routes
• and we want to use react-router 4
• everything working with HMR

The problem with async imports when using Redux and Sagas

We need to inject page stores into the main root store on the fly, and can’t import them right inside of rootReducer, same applies for Sagas.

First I started with building HOC for resolving async imports, I found, that the great solution for this is to use react-loadable which provides also preloading feature and I also wanted to be real badass and cool so that’s maybe why used it. We don’t have to do it only route centric, that’s really awesome, but for simplicity of this example, we are. (you can use it for preloading any of your components)

 const asyncRoute = getRoute => Loadable({
  loader: getRoute,
  loading() {
    return <Loading />
  },
  render(route, props) {
    const { Component, reducer, sagas } = route.default
    if (sagas) {
      injectAsyncSagas({
        name: sagas.name,
        sagas: sagas.sagas,
        store
      })
    }
    if (reducer) {
      injectAsyncReducer({
        name: reducer.name,
        asyncReducer: reducer.reducer,
        store
      })
    }
    return <Component {...props} />
  }
})

Here is how it’s done inside of my asyncRoute HOC. All responsibility of loading my chunk is passed to Loadable as you can see above, I’m just passing getRoute function from parameter which returns async ‘import()’ to the Loadable loader, it provides me with loading callback and also a render, where I’m handling injections of sagas and reducer. In route parameter of render function I got anything that was exported from the page. Usage:

const PageOne = asyncRoute(() => import('pages/PageOne'))

Here is what I’m exporting from the index of PageOne and that’s the object that I got up there. If there is no reducer or sagas, only component will be returned from our asyncRoute helper. We also need a name of reducer and sagas for injecting purposes.

import PageOne from './PageOne'
import reducer from './reducer'
import sagas from './sagas'

export default {
  Component: PageOne,
  reducer: {
    name: 'pageOneAuthor',
    reducer
  },
  sagas: {
    name: 'pageOneAuthor',
    sagas  
  }
}

Here you can find my asyncRoute helper together with PageOne export.

Next we will need to handle injecting ‘magic’ of reducers and sagas somehow. In our asyncRoute helper you have seen these calls.

   if (sagas) {
      injectAsyncSagas({
        name: sagas.name,
        sagas: sagas.sagas,
        store
      })
    }
    if (reducer) {
      injectAsyncReducer({
        name: reducer.name,
        asyncReducer: reducer.reducer,
        store
      })
    }

These functions are exported from store.js which configures our redux store with middlewares, initial state…

Here they are

export const injectAsyncReducer = ({ name, asyncReducer, store }) => {
  store.asyncReducers[name] = asyncReducer
  store.replaceReducer(createReducer(store.asyncReducers))
}

export function injectAsyncSagas({ name, sagas, store }) {
  if (!store.asyncSagas.includes(name)) {
    sagas.forEach(store.runSaga)
    store.asyncSagas.push(name)
  }
}

This is real magic happening. So basically what you can see here, that we tuned our store object and it now contains asyncSagas array of names and asyncReducers array of our injected reducers, this is how it’s going in West Coast Customs when store has 4 wheels. Maybe you are asking, where I got createReducer ? It’s imported from our rootReducer and looks like this :

export const createReducer = asyncReducers => combineReducers({ ...rootReducer, ...asyncReducers })

Here is how we tuned our store object in configureStore function in store.js, to be able to inject sagas and reducers.

  store.runSaga = sagaMiddleware.run
  store.asyncReducers = store.asyncReducers || {}
  store.asyncSagas = store.asyncSagas || []

If you look into store.js export, we are calling configureStore({}), so we are able to use already configured store in asyncRoute, if you wan’t to do some other Dan Abramov stuff with store like caching it… , you will need to pass initialState there, which is now just plain object.

HMR

You want to be cool and show to your friends how you rockin with hot… module replacement ? This is the right place to look at it’s implementation.

This needs to be added into configureStore function to achieve hot replacement of reducers.

if (process.env.NODE_ENV === 'development') {
    if (module.hot) {
      module.hot.accept('./rootReducer', () => {
        store.replaceReducer(createReducer(store.asyncReducers))
      })
    }
  }

And for everything else you will need to add this into your index.js

if (module.hot && process.env.NODE_ENV !== 'production') {
  module.hot.accept('./App', () => {
    ReactDOM.render(<Provider store={store}><App /></Provider>, rootEl)
  })
}

Here are the results:

found out that backend.js is just from react devTools, I never seen that before, thought someone is mining crypto on my computer (look to that app name in chrome store fmkadmapgofadopljbjfkapdkoienihi) so don’t care about that.

What can be seen here that bundle.js loaded first, 1.chunk.js is preloaded in App.js and 0.chunk.js was loaded after I routed to the page that represents it. Cool huh ?

This is how it looks like in our state before and after we navigate to the page with async loaded reducer.

HERE you will find my repository where you can check it out, run and inspect what’s happening.

Follow me on twitter :))